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Abstract 

Current  computer  generated  forces  (CGFs)  in  the  “synthetic  battlespace” ,  a  training 
arena  used  by  the  military,  exhibit  several  deficiencies.  Human  actors  within  the  bat¬ 
tlespace  rapidly  identify  these  CGFs  and  defeat  them  using  unrealistic  and  potentially 
fatal  tactics,  reducing  the  overall  effectiveness  of  this  training  arena.  Simulators  attached 
to  the  synthetic  battlespace  host  local  threat  systems,  leading  to  training  inconsistencies 
when  different  simulators  display  the  seime  threat  at  different  levels  of  fidelity.  Finally,  cur¬ 
rent  CGFs  are  engineered  “from  the  groimd  up”,  often  without  exploiting  commonalities 
with  other  existing  CGFs,  increasing  development  (and  ultimately  training)  costs. 

This  thesis  addresses  these  issues  by  proposing  a  domain-independent  design  method¬ 
ology  and  a  supporting  software  architecture  for  the  Distributed  Mission  Training  Inte¬ 
grated  Threat  Environment  (DMTITE).  This  architecture  uses  approaches  from  software 
engineering  and  database  management  and  identifies  an  extensible  knowledge  representa¬ 
tion  to  support  CGFs  in  various  domains  (l2ind,  surface,  and  air),  shifting  development 
efforts  from  “structure  implementation”  to  “knowledge  implementation.”  CGFs  developed 
using  this  paradigm  also  have  access  to  domain-independent  features  such  as  skills  vectors 
and  a  combat  psychology  model,  which  act  as  a  time-limited  Turing  test  by  making  CGF 
behaviors  impredictable  (but  not  random)  and  believable. 
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A  REPRESENTATIONAL  APPROACH  TO  KNOWLEDGE  AND 


MULTIPLE  SKILL  LEVELS  FOR  BROAD  CLASSES  OF 
COMPUTER  GENERATED  FORCES 

/.  Introduction 

To  make  better  use  of  limited  Department  of  Defense  training  funds,  the  military  has 
turned  to  Distributed  Interactive  Simulation  (DIS)  technology  and  concepts  such  as  the 
Joint  Synthetic  Battlespace  (JSB)  as  training  arenas.  These  concepts  and  technologies, 
although  successful  in  certmn  areas,  exhibit  several  deficiencies  resisting  from  participant 
and  environment  inconsistencies. 

A  major  problem  is  the  threat  environment  (e.g.,  anti-cdrcraft  artillery  or  aircraft) 
currently  presented  to  simulation  participants  is  not  consistent.  This  inconsistency  pre¬ 
vents  battlespace  combatants  from  interacting  in  a  realistic  fashion  because  they  sense  the 
environment  at  different  fidelity  levels.  For  example,  simulators  of  combat  force  aircraft 
have  native  threat  generation  systems  for  stand-alone  and  network  testing.  This  heteroge¬ 
neous  capability  often  results  in  compatibility  problems  between  simulators  when  adding 
new  weapons  or  theaters  of  operation.  A  contributing  problem  is  many  battlespace  sys¬ 
tems  representing  the  same  asset  are  implemented  in  a  non-uniform  manner — that  is,  they 
are  built  “from  the  groimd  up.”  Many  simidator  developers  create  unique  systems  and 
implement  modeling  decisions  supporting  their  users  in  specific  scenarios.  These  differing 
systems  are  difficult  to  coordinate  on  a  distributed  network  because  they  can  not  perform 
at  the  s^lme  fidelity  level,  creating  eisset  synchronization  issues. 

Lastly,  there  is  a  lack  of  “intelligent”  computer-generated  actors  within  most  cmrent 
military  simulations.  Humans  are  able  to  rapidly  identify  and  defeat  current  computer¬ 
generated  entities  using  unrealistic  tactics  {i.e.,  “gaming  the  system”),  reinforcing  poten¬ 
tially  fatal  behaviors.  The  current  situation  detracts  from  the  effectiveness  of  training 
conducted  in  virtual  training  arenas  such  as  the  “synthetic  battlespace.” 
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Taken  together,  these  issues  lead  to  great  expense,  uncoordinated  threat  develop¬ 
ment,  and  training  inconsistencies  between  participants.  A  promising  technology  to  fill 
this  gap  is  Computer-Generated  Forces  (CGFs) — computer  controlled  actors  representing 
combatemts  and  displaying  behavior  based  on  current  battlespace  state  information.  Large 
numbers  of  simulation  CGFs  could  be  created  on  demand  with  minimal  cost,  and  can  be 
standardized  in  their  presentation  of  and  re2iction  to  threats  throughout  the  battlespace. 

1.1  Distributed  Mission  Training  Integrated  Threat  Environment  (DMTITE) 

Research  discussed  in  this  thesis  was  conducted  in  support  of  DMTITE,  a  proposed 
training  environment  that  will  support  aircrew  training  by  inserting  a  variety  of  accurate 
and  realistic  threats  into  large-scale  distributed  virtual  environments.  The  system  will 
be  hosted  on  one  or  more  computer  systems;  therefore,  each  must  be  able  to  operate 
autonomously  and  also  cooperate  with  other  DMTITE  systems  to  portray  a  coordinated 
threat  environment.  Each  DMTITE  system  will  require  access  to  a  common  script  for  each 
training  scenario  and  will  inject  threats  (hostile  aircraft,  radar,  electronic  countermeasures 
(ECM),  surface-to-air  missile  (SAM)  sites,  and  anti-aircraft  artillery  (AAA)  batteries)  into 
the  synthetic  battlespace.  Since  the  DMTITE  system  will  replace  the  threat  generation 
systems  currently  local  to  each  simulator,  human  actors  operating  in  the  same  domain  of 
the  synthetic  battlespace  will  perceive  a  threat  at  a  common  level  of  fidelity. 

This  research  is  sponsored  by  the  United  States  Air  Force’s  Aeronautical  Systems 
Center  (ASC),  Air  Force  Materiel  Command  (AFMC),  Wright-Patterson  Air  Force  Base, 
Ohio. 


1.2  Scope 

This  thesis  addresses  two  of  the  goals  of  the  DMTITE  project.  First,  it  identifies  a 
knowledge  engineering  approach  for  instantiating  the  broad  classes  of  actors  maintained  by 
the  DMTITE  system.  This  approach  addresses  many  of  the  requirements  identified  during 
the  course  of  the  DMTITE  project,  but  allows  developers  flexibility  in  the  tools  they 
use  to  implement  DMTITE  actors.  Second,  this  thesis  identifies  the  domain-independent 
software  architecture  developed  to  support  DMTITE  knowledge  engineering  efforts.  This 
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architecture  extends  a  previously  implemented  architecture,  attempting  to  shift  the  CGF 
development  focus  from  “structure  implementation”  to  “knowledge  implementation.” 

1.3  Overview 

Chapter  11  frames  this  research  by  exploring  much  of  the  bEickground  of  the  DMTITE 
project.  Terms  used  throughout  this  thesis  are  defined,  related  efforts  are  identified,  and 
overviews  of  relevant  concepts  are  presented.  Chapter  HI  identifies  a  “knowledge-centric” 
design  methodology  for  implementing  CCFs.  The  assumptions,  goals,  and  components 
of  this  design  methodology  are  discussed,  and  its  strengths  and  weaknesses  are  identified. 
Chapter  IV  maps  the  design  methodology  discussed  in  the  previous  chapter  to  a  domain- 
independent  software  architectime.  The  components  of  the  circhitecture  are  decomposed 
and  discussed  in  detail.  Finally,  Chapter  V  identifies  the  expected  results  of  this  paradigm 
as  well  as  avenues  for  futme,  related  research. 
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II.  Background 

This  chapter  introduces  the  topics  of  distributed  virtual  environments  (DVEs),  includ¬ 
ing  the  Distributed  Interactive  Simulation  (DIS)  protocol  and  the  High-Level  Architec¬ 
ture  (HLA);  current  computer  generated  force  (CGF)  background  2ind  relevant  projects; 
and  the  Common  Object  Database  (CODE)  system  architecture.  These  topics  form  the 
groundwork  for  the  DMTITE  architecture  and  its  operational  environment.  The  topic  of 
knowledge  acquisition  is  also  discussed  since  it  applies  to  the  research  addressed  in  this 
thesis. 

2.1  Frequently  Used  Terms 

Many  of  the  terms  used  throughout  this  thesis  are  standard  within  the  cirtificial 
intelligence  and  simulation  communities;  however,  the  following  terms  are  defined  explicitly 
for  those  readers  unfamiliar  with  them. 

2.1.1  Entities.  An  entity  is  a  component  of  a  distributed  virtual  environment 
whose  state  can  change.  Combatants  (whether  human-  or  computer-controlled)  are  entities; 
terrain  (whose  appearance  and  features  can  be  changed  as  a  result  of  plowing,  explosions, 
or  traffic)  is  also  an  entity. 

2.1.2  Actors.  An  actor  is  an  entity  that  moves  with  apparent  intelligent  pur¬ 
pose.  Actors  can  be  virtual  (human-controlled),  constructive  (traditional  simulation  con¬ 
trolled),  live  (derived  firom  instrumented  range  data),  or  computer-generated  (controlled 
by  a  computer  program  employing  artificial  intelligence  techniques).  Obviously,  all  actors 
are  entities;  however,  not  eiU  entities  eire  actors  (i.e.,  terrain).  Computer  generated  forces 
are  computer  generated  actors  representing  combatants  in  a  virtual  battlespace;  for  the 
purposes  of  this  thesis,  the  two  terms  are  considered  synonymous. 

2.1.S  Hosts.  A  host  is  a  computer  system  within  a  DVE  that  allows  human 
and/or  computer  user(s)  to  control  actors  or  entities  within  the  distributed  virtual  en- 
viromnent.  A  host  also  allows  its  users  to  observe  the  actions  of  other  entities  within 
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the  DVE,  whether  the  other  entities  are  hosted  on  the  same  system  or  another  (possibly 
remote)  computer  system. 

2.2  Distributed  Virtual  Environments 

The  DoD  realized  the  usefulness  of  distributed  virtual  environments  in  the  early 
1980s,  when  the  Army  networked  its  tank  simiilators  through  SIMNET  (36).  Although 
successful  in  providing  a  DVE  for  armor  and  other  ground  vehicles,  SIMNET  remained 
limited  to  that  domain.  In  1989,  the  DoD  initiated  the  Distributed  Interactive  Simu¬ 
lation  protocols  and  in  1995  initiated  the  High  Level  Architecture.  These  two  network 
technologies  are  the  most  widely  used  for  DVEs  today. 

2.2.1  Distributed  Interactive  Simulation.  The  DIS  suite  of  standards  (IEEE  Stan¬ 
dard  1278)  was  designed  to  link  distributed,  autonomous  hosts  into  a  real-time  distributed 
virtU2J  environment.  In  DIS,  this  is  accomplished  through  a  network  that  exchanges  data 
describing  events  (such  as  collisions,  weapons  firings,  and  detonations)  and  activities  (such 
as  the  movement  of  an  actor  through  the  virtual  environment).  DIS  is  the  epitome  of  an 
asynchronous  network:  there  is  no  central  computer,  event  scheduler,  clock,  or  conflict 
arbitration  system.  Stytz  provides  additional  information  regarding  DVEs  and  DIS  (33), 
as  does  Blau  (5,  6). 

2.2.2  High-Level  Architecture.  As  the  heir  apparent  to  DIS,  the  High-Level  Archi¬ 
tecture  (HLA)  takes  a  more  comprehensive  approeich  to  communication  and  basic  system 
requirements.  The  stated  goal  of  HLA  is  to  establish  an  architectural  framework  supporting 
interoperability  between  different  simulations.  A  central  architectural  decision  supporting 
this  go^J  is  the  sep^lration  of  application  functions  (managed  by  a  host  application  soft¬ 
ware  system)  from  communications  junctions  (managed  by  the  Runtime  Infrastructure,  or 
RTI).  The  RTI  manages  communication  paths  between  executing  applications,  ensures  its 
applications  acquire  the  data  they  subscribed  to,  and  publishes  data  other  applications 
request.  The  RTI  “publish  and  subscribe”  mechanism  reduces  the  amount  of  data  trans¬ 
mitted  between  applications  to  only  that  requested  by  the  applications.  The  foimdational 


2-2 


papers  for  HLA  axe  contained  in  the  15th  Workshop  on  Standards  for  the  Interoperability 
of  Distributed  Simulations  (8,  11,  14,  24,  32). 

2.3  Computer  Generated  Forces 

Computer  generated  forces  (CGFs)  are  computer-controlled  actors  in  a  distributed 
virtual  battlespace.  In  general,  CGFs  attempt  to  model  either  human  cognition  or  human 
behavior  in  combat;  approaches  to  achieving  realistic  CGFs  are  described  by  Calder,  et 
al.  (7),  Edwards  (13),  Laird  (19,  20),  cind  Tambe  (35).  The  runtime  challenges  for  a  CGF 
arise  from  the  need  to  compute  human  behaviors  and  reactions  to  a  complex  dynamic 
environment.  Other  research  (such  as  TacAir-Soax)  addresses  this  challenge  by  attempting 
to  emulate  the  human  cognitive  process  (19).  On  the  other  hand,  this  research  assumes  that 
simulating  the  observable  aspects  of  human  decision  making  is  sufficient.  This  assumption 
somewhat  eases  the  computational  requirements  of  a  CGF. 

Unfortimately,  many  rapidly  developed  CGFs  fail  to  display  realistic  and  accurate 
outputs  when  compared  to  human  counterparts.  This  modeling  deficiency  allows  htunan- 
controlled  actors  to  easily  identify  their  computer-controlled  counterparts,  thus  yielding 
an  unrealistic  advantage  to  and  reinforcing  potentially  fatal  behaviors  in  the  participants 
being  trained.  Both  the  physical  and  mental  representations  of  a  CGF  must  be  realistically 
modeled  to  ensure  realistic  outputs.  Karr,  et  al.,  present  an  overview  of  the  requirements  for 
and  current  deficiencies  in  CGF  representations  (18);  Santos,  et  al.  (27),  emd  Rosenbloom, 
et  al.  (25),  present  approaches  for  developing  “human-like”  CGF  mental  representations. 

2.4  Common  Object  Database  Architecture 

The  Common  Object  Database  (CODE)  is  a  data-handling  architecture  that  uses 
object  classes,  containerization,  eind  a  central  runtime  repository  to  manage  and  route 
data  between  applications  in  a  distributed  virtual  environment  (34).  There  can  be  multiple 
CODBs  on  a  single  host,  most  of  which  will  contain  only  the  information  required  by  the 
applications  directly  connected  to  them.  One  CODE,  however,  must  maintain  the  entire 
current  state  of  the  DVE  via  a  “world  state  manager”  (WSM).  The  WSM  sends  and  receives 
networked  information  about  entities  in  a  distributed  simulation;  calculates  entity  positions 
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via  dead  reckoning  between  updates;  and  converts  network  messages  to  their  corresponding 
CODE  container  data  structures.  It  is  the  responsibility  of  each  subordinate  CODE  to 
ensure  the  appropriate  information  propagates  both  to  and  from  the  WSM  CODE. 

Stytz,  et  al.  (34)  describes  the  CODE  architecture.  The  CODE  approach  and  imple¬ 
mentation  used  in  support  of  this  research  are  discussed  in  Appendix  A. 

2.5  Knowledge  Acquisition 

Knowledge  acquisition  consists  of  two  tasks,  both  essential  to  the  development  of 
knowledge-based  systems  such  as  CGFs.  During  knowledge  elicitation,  a  knowledge  engi¬ 
neer  gathers  knowledge  from  sources  such  as  domain  experts,  books,  reports,  md  visual 
inspection  (15).  Once  a  sufficient  amount  of  knowledge  is  obtained,  a  knowledge  represen¬ 
tation  is  used  to  convert  it  to  a  computer-readable  format.  This  process  is  often  iterative, 
and  is  discussed  in  great  detail  by  Gonzalez  and  Dankel  (15).  Examples  of  knowledge  acqui¬ 
sition  techniques  for  CGFs  include  “semantic  areas  of  concern”  used  by  Zmita  (38)  during 
the  Intelligent  Wingman  project,  and  “storyboarding”,  utilized  by  Eanks  and  Lizza  (21) 
to  implement  the  Pilot’s  Associate. 
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III.  DMTITE  Design  Methodology 

DMTITE  is  designed  to  allow  human  pilots  to  train  against  a  variety  of  threat  systems, 
some  of  which  operate  in  the  same  domain  as  the  pilots,  some  of  which  do  not.  For  ex¬ 
ample,  opposing  aircraft  operate  in  the  same  domain  as  human  pilots,  while  land-based 
radar  and  electronic  countermeasure  (ECM)  systems  do  not.  Further  complicating  mat¬ 
ters  are  threats  that  operate  in  multiple  domains,  such  as  surface-to-air  missile  (SAM) 
and  anti-aircraft  artillery  (AAA)  sites — ^land-based  entities  which  generate  airborne  enti¬ 
ties  (e.g.,  missiles  and  bullets).  CGFs  simulating  these  threats  require  different  knowledge, 
teictics,  and  physical  models  to  accurately  portray  a  realistic  threat  environment.  Current 
CGF  development  efforts  build  entities  “from  the  ground  up”,  factoring  the  domain  of 
interest  into  early  design  decisions,  resulting  in  a  software  architecture  tightly  coupled  to 
that  domain.  Commonalities  between  CGFs  are  often  overlooked  since  similar  CGFs  are 
often  viewed  as  having  distinct  and  different  roles  and  responsibilities  within  the  virtual 
battlespace.  The  use  of  proprietary  software  development  tools  and  practices  further  com¬ 
plicates  matters  since  they  are  not  transferable  to  other  CGF  development  efforts.  The 
results  of  these  practices  eire  higher  development — and  ultimately  training — costs,  as  well 
as  a  lack  of  coordination  between  CGFs. 

Identifying  a  design  methodology  to  rapidly  design,  implement,  and  test  DMTITE 
CGFs  addresses  these  concerns  in  several  ways.  First,  a  design  methodology  defines  a 
standard  approach  for  developing  CGFs,  addressing  the  software  engineering  concept  of 
reuse  by  encoiiraging  developers  to  evaluate  new  requirements  in  terms  of  existing  CGF 
implementations.  As  a  result,  work  duplicated  among  multiple  CGF  development  efforts 
is  minimized.  Second,  a  design  methodology  serves  as  a  roadmap,  helping  both  knowledge 
and  software  engineers  identify  the  type  and  scope  of  work  to  be  accomplished.  This 
allows  CGFs  to  be  developed  in  a  more  effective  and  efficient  manner.  Finally,  identifying  a 
design  methodology  allows  a  software  architectme  to  be  implemented  in  support  of  it.  This 
architectture  becomes  a  tool  of  the  methodology,  shifting  development  efforts  from  structure 
implementation  (concerns  such  as  processing  fiow  and  interprocessing  communication)  to 
knowledge  implementation  (the  specific  knowledge  and  state  information  required  by  a 
CGF).  Actual  software  development  is  then  limited  to  designing  and  implementing  physical 
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models  not  yet  incorporated  as  part  of  the  software  architecture,  resulting  in  a  more  efficient 
manner  of  developing  CGFs. 

3.1  Goals  of  the  Design  Methodology 

The  first  goeil  of  the  DMTITE  design  methodology  was  to  avoid  specifying  knowledge 
elicitation  and  documentation  techniques  to  be  used.  The  design  methodology  needed  to 
be  fiexible  enough  to  allow  knowledge  engineers  to  use  whatever  techniques  are  available 
and  appropriate.  Another  goal  of  the  DMTITE  design  methodology  was  to  minimize  the 
amount  of  duplicate  knowledge  used  to  implement  a  CGF.  This  goal  is  similar  to  the 
concept  of  centralized  control  in  database  systems  (12);  it  controls  redundancy,  helps  avoid 
inconsistencies  in  the  knowledge,  and  maintains  knowledge  integrity.  A  third  goal  was  to 
identify  a  taxonomy  capable  of  supporting  a  domain-independent  approach  to  developing 
CGFs  while  acknowledging  the  fact  that  each  domain  requires  knowledge  not  shared  by 
other  domains.  A  final  goal  of  the  design  methodology  was  to  incorporate  the  identification 
of  “knowledge  modifiers”  into  the  CGF  development  cycle.  With  such  wide  ranging  goals, 
then,  the  ultimate  goal  of  this  design  methodology  is  to  identify  components  essential  to 
the  development  of  a  CGF  (regardless  of  domain),  then  to  bring  those  components  together 
in  a  cohesive,  usable  maimer. 

3.2  Knowledge  Representations 

While  the  design  methodology  assumes  a  suitable  method  of  eliciting  iind  document¬ 
ing  knowledge  to  construct  a  CGF  exists,  at  some  point  that  knowledge  must  be  mapped  to 
a  single  representation  supporting  multiple  inferencing  strategies.  A  single  representation 
allows  knowledge  to  be  accessible  to  any  inferencing  strategy  with  only  minimal  modifi¬ 
cation,  reducing  the  work  required  to  inference  over  knowledge  originally  implemented  for 
some  other  inferencing  strategy.  Furthermore,  this  representation  must  support  the  goal 
of  minimizing  the  amoimt  of  duplicate  knowledge  in  the  system.  This  allows  knowledge  to 
be  added,  deleted,  or  modified  in  an  efficient  and  effective  manner.  Finally,  while  not  an 
explicit  goal  of  the  design  methodology,  the  knowledge  representation  shouldn’t  prevent 
the  knowledge  from  being  dynamically  added,  removed,  or  modified  by  the  CGF. 
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3.2.1  Knowledge  Expressions.  At  the  lowest  level,  the  knowledge  representation 
must  be  able  to  express  knowledge  in  the  form  of  rules,  facts,  and  so  forth  in  a  manner 
usable  (or  at  least  decipherable)  by  an  inferencing  strategy.  For  DMTITE  CGFs,  three 
possible  inferencing  strategies  were  identified:  case-based  reasoning,  rule-based  reasoning, 
eind  fuzzy  logic.  Since  each  of  these  inferencing  strategies  have  been  demonstrated  to  be 
computable,  they  can  be  derived  from  primitive  recursive  functions  (22);  that  is,  they  are 
derived  from  a  common  set  of  predicates.  These  predicates  can  be  expressed  as  if-then  (or 
if-then-else)  expressions;  as  a  result,  these  terms  are  used  to  express  the  knowledge  used 
by  ciny  of  the  inferencing  strategies  supported  by  DMTITE. 

However,  the  traditional  variables  contained  in  most  if-then  terms  do  not  fully  sup¬ 
port  fuzzy  logic.  A  knowledge  representation  supporting  fuzzy  logic  must  support  not 
only  “crisp”  (traditional)  variables,  but  also  “fuzzified”  variables  (representing  a  range  of 
values).  Since  this  is  the  only  difference  between  a  traditional  if-then  term  and  a  “fuzzy”  if- 
then  term,  an  extensible  knowledge  representation  is  readily  identifiable  and  implemented. 
(The  knowledge  representation  used  in  DMTITE  is  discussed  in  Appendix  C). 

3.2.2  Policies:  “Atomic”  Knowledge  Bases.  At  a  higher  level  of  abstraction, 
the  knowledge  representation  must  support  knowledge  bases  comprised  of  smaller,  more 
“atomic”  knowledge  bases.  Borrowing  a  term  coined  by  Earl  Cox  in  support  of  his 
Fuzzy  Modeling  System  (10),  these  “atomic”  knowledge  bases  are  policies — logical  and 
self-contained  units  of  knowledge.  This  knowledge  representation  has  two  significant  ad¬ 
vantages.  First,  it  supports  the  goal  of  minimizing  the  amount  of  duplicate  knowledge  in 
DMTITE.  For  example,  a  given  aircraft  CGF  might  define  an  “offensive  postmre”  knowl¬ 
edge  base  as  consisting  of  an  “offensive  maneuvers”  policy  and  a  “known  enemy  maneuvers” 
policy,  while  defining  a  “defensive  posture”  knowledge  base  in  terms  of  a  “defensive  ma¬ 
neuvers”  policy  and  the  same  “known  enemy  maneuvers”  policy  (Figure  3.1).  Additional 
enemy  maneuvers  can  then  be  added  to  a  single  policy  while  being  reflected  in  both  knowl¬ 
edge  bases.  The  other  adv2intage  of  this  knowledge  representation  is  knowledge  abstraction. 
Just  as  data  abstraction  edlows  use  of  an  object  without  knowledge  of  its  underlying  data 
structure,  knowledge  abstraction  allows  an  entity  to  access  a  knowledge  base  seemingly 
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common  to  other  CGFs,  but  consisting  of  different  policies.  For  example,  CGFs  may 
search  for  threats  using  optical  sensors  (“eyes”),  r2idar,  or  both.  A  general  search  knowl¬ 
edge  base  can  be  defined  consisting  of  policies  specific  to  the  sensors  available  to  a  given 
CGF  (Figure  3.2).  Furthermore,  the  general  search  knowledge  base  can  be  incrementally 
implemented  and  tested  by  including  each  of  its  constituent  policies  one  at  a  time. 

3.2.3  Knowledge  Repository.  At  the  final  level  of  abstraction,  the  knowledge 
representation  should  allow  knowledge  to  be  centralized.  This  centralized  nature  allows 
knowledge  to  be  globally  av2dlable  to  all  inferencing  engines  requiring  it,  but  doesn’t  require 
each  engine  to  maintain  a  local  copy  of  the  knowledge  it  uses.  Centralization  of  knowledge 
also  allows  engines  to  add,  delete,  and  modify  knowledge  bases  in  a  manner  that  makes 
such  changes  available  to  all  engines  using  those  knowledge  bases.  If  an  inferencing  en¬ 
gine  requires  a  locd  copy  of  the  knowledge  (for  instance,  the  knowledge  representation  is 
not  directly  supported  by  the  inferencing  strategy),  this  approach  permits  such  copies  to 
be  made.  The  flexibility  of  a  knowledge  repository  makes  the  design  methodology  more 
attractive  to  both  knowledge  and  software  engineers. 

3.3  Knowledge  “Modifiers” 

CGFs  should  display  multiple  skill  levels  in  a  manner  similar  to  those  displayed 
by  human  actors  and  the  design  methodology  must  identify  a  means  of  capturing  this 
information.  Since  the  presence  of  skills  is  reflected  in  the  behavior  of  a  combatant,  and 
the  behavior  of  CGFs  is  based  on  the  knowledge  available  to  that  CGF,  skills  are  essentially 
“knowledge  modifiers.”  For  ex2imple,  an  anti-eiircraft  artillery  CGF  with  little  weapons  skill 
may  display  this  by  firing  at  targets  out  of  range,  while  an  identical  CGF  with  more  skill 
would  wait  until  the  target  is  within  weapons  reinge.  While  eliciting  and  docmnenting 
knowledge,  the  knowledge  engineer  should  identify  the  presence  of  skills  in  the  domain 
experts.  Differences  between  the  actions  described  by  a  domain  expert  and  the  actions 
dictated  by  doctrine  are  one  example  of  the  presence  of  skills.  Unfortunately,  no  one 
method  can  identify  the  presence  eind  effect  of  skills;  as  a  result,  the  knowledge  engineer 
must  carefully  analyze  acquired  knowledge  and  determine  if  skills  eiffect  it. 
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Maneuvers 

Figure  3.1  Shared  Policy  Example 

How  skills  affect  knowledge  is  no  easier  to  identify.  In  most  cases,  the  skills  will 
indirectly  affect  knowledge  by  modifying  the  information  that  triggers  it.  Returning  to  the 
previous  example,  the  imskilled  AAA  CGF  extends  the  firing  range  of  its  weapon  beyond 
its  actual  limit.  One  way  of  reflecting  this  is  to  determine  the  farthest  range  an  unskilled 
operator  would  fire  at  and  derive  a  mathematical  fimction  that  reduces  the  range  as  skill 
increases.  Another  approach  would  be  to  determine  the  aw:tual  firing  range  of  a  weapon, 
then  derive  a  mathematical  equation  that  extends  that  range  as  skill  decreases.  Again, 
how  the  skill  ultimately  affects  the  knowledge  is  left  to  the  judgment  of  the  knowledge 
engineer;  however,  the  ultimate  goal  here  is  to  reflect  actual  observations  into  the  synthetic 
battlespace. 

3.4  A  Supporting  Taxonomy 

An  approach  that  assumes  a  single  cognitive  representation  for  multiple  CGFs  implies 
a  taxonomy  exists  for  the  CGFs  in  question.  In  the  case  of  distributed  virtual  environments, 
the  DoD  developed  such  a  taxonomy,  albeit  embedded  in  the  DIS  standard  (IEEE  1278.1- 
1995).  In  DIS,  the  “Entity  State”  Protocol  Data  Unit  (PDU)  defines  (among  other  things) 
the  category  to  which  a  CGF  belongs  (17).  This  information  is  the  ideal  basis  for  a 
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taxonomy,  if  one  accepts  these  categories  as  defining  the  various  mission  platforms  within 
the  land,  surface,  air,  and  space  domains. 

Although  DMTITE  is  capable  of  supporting  space-based  CGFs,  this  domain  is  no¬ 
tably  missing  from  the  taxonomy.  The  DIS  standard  includes  a  very  limited  taxonomy 
of  spjice-based  entities,  dividing  them  into  two  categories  (“manned”  and  “unmanned”), 
and  enumerating  only  the  U.S.  Space  Shuttle  fleet  under  the  “manned”  category.  The 
DIS  taxonomy  (and  the  corresponding  DMTITE  taxonomy)  reflect  the  current  political 
agreements  banning  space-based  weapon  systems.  Obviously,  if  the  political  environment 
changes,  a  teixonomy  for  the  space  domain  will  need  to  be  implemented. 

3.5  A  “Knowledge-Centric”  Design  Methodology 

The  design  methodology  (discussed  in  detail  in  Appendix  B)  resulting  from  the  in¬ 
corporation  of  the  components  identified  in  this  chapter  consists  of  two  parts.  The  first 
half  focuses  on  what  knowledge  is  necessary  to  instantiate  a  CGF  category  within  a  given 
domain  (e.g.,  land,  air,  surfeice)  in  the  DMTITE  taxonomy.  During  this  phase  of  develop¬ 
ment,  a  knowledge  engineer  elicits  and  documents  knowledge  from  the  appropriate  somrces, 
groups  related  knowledge  into  policies,  and  determines  the  inferencing  strategies  to  be  em- 
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Figxire  3.3  Initial  DMTITE  Taxonomy 

ployed  by  the  CGF.  While  acquiring  knowledge,  the  knowledge  engineer  also  identifies 
knowledge  “modifiers”  (expressed  as  skills  and  other  operator  capabilities)  and  determines 
how  these  affect  the  knowledge  in  question.  When  this  phase  of  the  methodology  is  com¬ 
plete,  the  knowledge  engineer  has  developed  the  cognitive  representation  for  a  category  of 
CGFs  in  the  DMTITE  methodology.  The  first  half  of  the  design  methodology  is  the  most 
time-consuming  aspect  of  developing  knowledge-based  systems  such  as  CGFs  (15),  but 
should  be  conducted  fully  only  once  for  each  CGF  category.  As  additional  knowledge  is 
identified  for  inclusion  within  a  CGF  category,  the  knowledge  engineer  will  need  to  revisit 
this  phase  of  development,  although  these  efforts  should  be  smaller  in  scope  than  the  initial 
development  effort. 

On  the  other  hand,  the  second  phase  of  the  methodology  will  most  likely  occur  every 
time  a  new  CGF  type  (e.g.,  F-15,  F-16,  F-22)  within  a  category  is  instantiated.  In  this 
phase,  the  knowledge  engineer  works  closely  with  a  software  engineer  to  ensure  the  proper 
information  is  used  to  invoke  the  CGF’s  knowledge.  Physical  models  are  identified  and,  as 
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necessary,  designed,  developed,  and  tested.  The  information  provided  by  these  models  is 
mapped  to  the  information  required  by  the  cogmtive  representation.  In  short,  when  this 
phase  is  complete,  the  knowledge  and  software  engineers  have  identified  and  implemented 
the  information  upon  which  the  CGF  will  base  its  behaviors.  Since  this  includes  simulation- 
specific  information  such  as  weapon  loadouts,  fuel  levels,  and  so  forth,  this  phase  of  the 
methodology  will  most  likely  be  performed  each  time  a  CGF  is  to  be  instantiated  for  use 
in  a  distributed  simulation. 

This  design  methodology  is  “knowledge-centric”  since  it,  in  its  first  phase,  is  con¬ 
cerned  with  what  knowledge  is  required  by  a  CGF  (or  category  of  CGFs)  and  how  that 
knowledge  is  modified  through  skills  and  other  capabilities  while,  in  its  second  phase,  it 
focuses  on  how  that  knowledge  is  invoked.  The  knowledge  and  software  engineer  no  longer 
are  concerned  with  essential  but  domain-independent  issues  such  as  how  the  CGF  commu¬ 
nicates  its  state  to  the  DVE.  In  fact,  the  design  methodology  itself  is  not  concerned  with 
such  issues;  instead,  it  assumes  these  concerns  are  integrated  into  the  underlying  software 
architecture. 
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IV.  A  Domain-Independent  Software  Architecture 

In  addition  to  supporting  the  design  methodology  outlined  in  Chapter  III,  the  DMTITE 
dom2iin-independent  architecture  is  required  to  fulfill  several  other  goals.  First,  the  soft¬ 
ware  architecture  must  be  able  to  support  live,  virtual,  and  constructive  simulations,  since 
each  of  these  are  used  in  military  training.  Second,  the  software  architecture  must  be 
flexible,  so  that  current  CGF  development  efforts  can  be  used  to  address  future  CGF  re¬ 
quirements.  Third,  the  architecture  must  support  domain-independent  concepts  such  as 
combat  psychology,  communication,  and  cooperation.  The  design  methodology  this  archi¬ 
tecture  supports  assumes  these  issues  are  addressed  by  the  architecture  and,  as  a  result, 
the  architectiure  must  allow  such  concepts  to  be  incorporated  with  no  effect  on  the  design 
methodology.  Finally,  the  software  architecture  must  address  the  concerns  of  CGF  behavior 
consistency,  unpredictability  and  certifiability.  Consistency  establishes  behaviors  reflecting 
a  given  state  of  the  virtual  environment;  in  other  words,  behaviors  that  are  not  random  or 
completely  ignore  the  environment  state.  Unpredictability  eliminates  exploitable  patterns 
in  CGF  behaviors.  Certifiability  measures  CGF  behaviors  against  human  behaviors  in 
similar  situations  (4). 

This  chapter  begins  by  describing  a  general  architecture,  the  first  step  in  meeting 
these  goals.  The  general  architecture  is  then  extended  to  encompass  domain-independence 
and  fiurther  address  impredictability  and  certifiability.  Next,  the  concepts  of  the  design 
methodology  and  the  components  of  the  extended  architecture  are  instantiated.  Finally, 
these  components  are  brought  together  to  establish  the  complete  and  integrated  DMTITE 
software  design. 

4.1  An  Existing  Architecture:  The  General  CGF  Architecture 

Santos,  et  al.  (27),  have  proposed  a  general  architecture  of  CGF  components.  Figme 

4.1  shows  this  architecture,  which  consists  of  a  physical  dynamics  component,  an  active 
decisions  component,  and  a  CGF  router.  The  key  of  this  architecture  lies  in  the  separation 
of  physical  and  cognitive  processes,  which  allows  several  advantages.  First,  it  minimizes 
dependencies  between  the  two  processes;  changes  to  one  do  not  necessarily  impact  the 
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other.  Second,  it  shifts  the  focus  from  what  knowledge  is  available  to  how  the  knowledge 
decomposes.  Fin2illy,  it  allows  instantiated  CGFs  to  display  a  wide  variety  of  abilities  and 
skills. 


DVE 

Figure  4.1  General  CGF  Architecture  (27) 


4.1-1  Physical  Dynamics  Component  (PDC).  The  PDC  consists  of  components 
modeling  a  CGF’s  physical  aspects:  kinematics  models,  sensor  models,  weapons  models, 
and  so  forth.  As  proposed  by  Santos,  et  al.  (27),  the  PDC  also  initializes  parameters  that 
give  a  CGF  a  specific  identity,  such  as  performance  specifications  and  operator  capabilities. 

4.1.2  Active  Decisions  Component  (ADC).  The  ADC  consists  of  four  compo¬ 
nents  that  use  information  from  the  PDC  to  m2ike  decisions.  The  Strategic  Decision  Engine 
(SDE)  is  concerned  with  high-level  functions  sudi  as  identifying,  implementing,  and  revis¬ 
ing  mission  goals.  The  Tactical  Decision  Engine  (TDE)  manages  the  moment-to-moment 
operations  of  the  entity,  such  as  determining  which  meineuvers  to  execute  or  weapons  to 
employ  in  a  given  situation.  The  Critical  Decision  Engine  (CDE)  represents  the  survival 
instinct  of  the  entity,  determining  if  an  emergency  situation  exists  and  (if  so)  what  actions 
to  take.  Finally,  a  Basic  Control  Module  (BCM)  converts  signals  from  the  decision  engines 
to  appropriate  physic^J  model  inputs. 
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4.1.3  CGF  Router.  The  CGF  router  is  the  interface  between  the  distributed 
virtual  environment  (DVE)  and  the  entity.  As  proposed  by  Santos,  et  al.  (27),  both  the 
PDC  and  ADC  directly  access  the  CGF  router. 

4.2  Extending  the  General  Architecture 

The  DMTITE  architecture  (shown  in  Figure  4.2),  originally  proposed  by  Van  Veld- 
huizen  and  Hutson  (37),  extends  the  general  architecture  to  support  both  a  domain- 
independent  approach  to  implementing  CGFs  and  address  the  concern  of  certifiability 
(which  is  only  partially  addressed  by  the  general  architecture).  The  high-level  mapping 
between  the  general  architecture  and  the  DMTITE  architecture  is  shown  in  Table  4.1  and 
discussed  in  the  following  sections. 


Figure  4.2  DMTITE  Software  Architecture 


4.2.1  Physical  Representation  Component  (PRC).  The  PRC  maps  closely  to 
the  PDC.  Like  the  PDC,  the  PRC  consists  of  physical  models  (such  as  those  identified 
previously).  These  physical  characteristics  axe  viewed  as  objects  and  operators;  the  result¬ 
ing  modularity  allows  for  easy  addition,  deletion,  and  modification  of  these  components 
without  requiring  corresponding  changes  to  the  cognitive  representation. 


Table  4.1  High-Level  Relationship  between  General  and  DMTITE  components 


General  Architecture 

DMTITE  Architecture 

Physical  Dynamics  Component 
Active  Decisions  Component 
Critical  Decision  Engine 

Tactical  Decision  Engine 
Strategic  Decision  Engine 

Basic  Control  Module 

CGF  Router 
(implicitly  defined) 

Physical  Representation  Component 
Cognitive  Representation  Component 
Critical  Decision  Engine 

Mission-Level  Decision  Engine 
Long-Term  Decision  Engine 
Arbitration  Engine 

Sensor  Interface 

Physical  State  Information  Interface 

However,  the  PRC  doesn’t  exactly  map  to  the  PDC.  The  PRC  is  comprised  strictly 
of  the  physical  attributes  and  properties  of  the  CGF;  those  characteristics  that  are  subject 
to  physical  laws.  Concepts  such  as  “skills”  and  “operator  capabilities”  don’t  observe  such 
laws  and  have  been  moved  to  the  cognitive  representation.  Another  significant  change  is 
that  the  PRC  represents  the  CGF’s  sole  communications  channel  to  the  DVE.  This  change 
was  made  to  more  closely  reflect  reality,  where  humans  are  forced  by  design  to  interact  with 
their  environment  directly  through  physical  processes.  In  the  case  of  the  CGF,  interaction 
is  hemdled  by  the  sensor  interface.  This  component  queries  the  DVE  for  information 
in  domains  of  interest  (such  as  land,  stuface,  or  air)  eind  relays  this  information  to  the 
physical  models.  The  sensor  interface  is  also  responsible  for  keeping  the  DVE  informed  of 
the  entity’s  existence  as  well  as  any  events  triggered  by  the  CGF  by  submitting  the  proper 
containers  to  the  local  CODE. 


4-2.2  Cognitive  Representation  Component  (CRC).  The  CRC  encompasses  CGF 
characteristics  that  are  less  physical  and  more  cognitive  in  nature.  It  is  responsible  for 
simulating  the  outcomes  of  the  human  cognitive  process  (decisions),  but  does  not  require 
a  model  of  the  cognitive  process  to  be  implemented.  While,  much  like  the  general  archi¬ 
tecture’s  CDC,  the  CRC  is  concerned  with  decision-making  and  eilso  contains  the  CGF’s 
goals,  entity  profile,  and  knowledge  bases. 

The  CRC,  much  like  the  CDC,  consists  of  three  decision  engines,  although  the  names 
were  changed  to  minimize  the  semantic  imp2ict  of  words  such  as  “tactical”  and  “strategic” 
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(since  these  terms  have  distinct  meaning  within  the  warfighting  communities).  The  Long- 
Term  Decision  Engine  (LTDE)  reasons  over  strategic  pl2ins  and  goals  of  concern  to  the 
CGF.  For  example,  it  allows  the  CGF  to  identify  “targets  of  opportunity”  that  advance 
the  ultimate  go^Js  of  the  simulated  mission,  but  were  not  part  of  the  CGF’s  original  tasking. 
The  Mission-Level  Decision  Engine  (MLDE)  reasons  over  moment-to-moment  and  short¬ 
term  actions  of  the  CGF.  Such  actions  include,  for  example,  initiating  a  bomb  drop  or 
attacking  enemy  aircraft.  The  Critical  Decision  Engine  (CDE)  is  the  only  engine  that 
remains  xmchanged  in  both  name  and  function  firom  the  general  CGF  architecture.  Like 
the  general  architecture,  the  DMTITE  architecture  has  three  decision  engines  scoped  to 
different  levels  and  tasks.  This  scoping  allows  fine-tuning  of  a  single  set  of  behaviors  (e.g., 
long-term  planning)  with  minimal  impact  on  other  behaviors.  Unfortunately,  each  engine 
will  most  likely  render  a  different  decision  for  the  same  situation. 

To  overcome  this  situation,  the  general  architecture’s  BCM  is  replaced  in  the  DMTITE 
architectme  with  an  Arbitration  Engine,  a  specialized  decision  engine  responsible  for  se¬ 
lecting  the  decision  ultimately  enacted.  The  Arbitration  Engines  polls  the  other  decision 
engines  and  considers  not  only  those  decisions,  but  3dso  each  decision’s  merits  relative  to 
the  current  state  of  the  entity  profile.  (The  entity  profile  is  discussed  in  detail  in  Section 
4.4.)  As  a  result,  the  Arbitration  Engine  can  simulate  abstract  concepts  such  as  “fear” 
(by  selecting  the  CDE’s  decision),  “bravery”  (by  ignoring  the  CDE’s  decision  and  choosing 
the  MLDE’s),  and  “indecisiveness”  (by  choosing  to  ignore  all  decisions).  In  short,  the 
Arbitration  Engine  ultimately  decides  the  course  of  auction  a  CGF  taikes  while  attempting 
to  simulate  human  behaviors  in  those  actions. 

The  final  component  of  the  CRC  is  the  Knowledge  Base  Repository.  This  repository 
maintains  the  sum  of  the  knowledge  available  to  the  CGF,  minimizing  the  duplication  that 
would  occur  if  each  decision  engine  maintained  local  copies  of  this  information.  Decision 
engines  access  this  knowledge  at  the  knowledge  base  level,  having  no  direct  access  to  the 
individual  policies  that  comprise  e2ich  knowledge  base.  While  not  part  of  this  research,  the 
Knowledge  Base  Repository  also  allows  knowledge  to  be  dynamically  added,  deleted,  and 
modified  in  one  location  while  affecting  multiple  decision  engines. 
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4-2.3  Physical  State  Information  Interface  (PSII).  The  PSII  is  the  CRC’s  sole 
source  of  state  information.  It  consists  of  a  variety  of  state  messages,  data  structures  that 
group  related  physical  state  information.  For  example,  the  state  message  representing 
a  hostile  entity  specifies  information  such  as  its  domain,  heading,  speed,  orientation,  and 
type.  Physical  models  place  state  messages  into  the  PSII,  and  the  CRC  can  retrieve  related 
state  messages  generated  by  different  physical  models  via  a  single  call  to  the  PSII. 

The  PSII  (as  well  as  the  Sensor  Interface  in  the  PRC)  supports  the  concept  of  data 
filtering,  shown  in  Figure  4.3.  “Pure”  state  information  is  manipulated  by  the  physical 
models  in  the  PRC  to  produce  “sensor-corrupted”  information,  which  is  stored  in  the  PSII. 
The  CRC  retrieves  this  “sensor-corrupted”  information  from  the  PSII,  corrupting  it  further 
by  adding  the  effects  of  the  entity  profile.  This  “sensor-  and  skill-corrupted  information” 
is  the  actual  information  used  by  the  CRC  to  make  decisions. 


Figure  4.3  Data  Filtering  in  DMTITE 

The  PSII  also  serves  as  the  repository  for  physical  model  control  information.  When 
the  Arbitration  Engine  decides  to  interact  with  the  DVE,  it  places  the  corresponding 
control  messages  in  the  PSII.  On  the  next  update  cycle,  each  controllable  physical  model 
queries  the  PSII  for  any  control  messages  eiffecting  it.  Any  applicable  control  messages 
are  acted  upon  by  the  physical  model.  Ultimately,  the  Sensor  Interface  gathers  the  effects 
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of  these  interactions  and  submits  the  information  to  the  local  CODE,  which  ultimately 
transmits  this  information  to  other  actors  in  the  synthetic  battlespace.  In  short,  the  CRC 
doesn’t  directly  interact  with  the  DVE;  instead,  it  interacts  with  its  physical  representation 
which,  in  turn,  propagates  these  interactions  to  the  DVE. 

4.2.4  Common  Object  Database  (CODE).  To  ensure  compatibility  with  the  cur¬ 
rent  Distributed  Interactive  Simulation  (DIS)  protocol  as  well  as  the  proposed  High-Level 
Architectme  (HLA)  protocol,  the  commimications  aspects  of  the  CGF  were  “removed” 
from  the  CGF  and  placed  in  the  domain  of  a  Common  Object  Database.  The  CODE 
serves  as  a  repository  for  information  being  distributed  to  and  collected  from  the  DVE. 
CGFs  inter2ict  with  the  CODE  through  the  use  of  data  containers:  the  CGFs  are  respon¬ 
sible  for  populating  their  portion  of  the  container  with  the  appropriate  information  and 
routing  it  to  the  CODE.  The  CODE  then  (conceptually)  “repackages”  this  information  to 
meet  the  requirements  of  the  communication  protocol  being  used.  As  long  as  the  CGF 
is  placing  the  proper  information  in  its  containers,  the  CODE  will  be  able  to  meet  the 
communications  requirements. 

Although  the  CODE  concept  has  been  in  place  at  AFIT  for  several  years,  it  has 
yet  to  be  fully  realized.  Several  simplifying  assumptions  have  been  made  regarding  its 
implementation,  rendering  it  not  much  more  them  a  memory  arena  utilized  by  different 
applications.  In  support  of  DMTITE,  the  CODE  concept  was  revisited  and  reimplemented 
(Appendix  A).  As  a  result,  DMTITE  CGFs  have  access  to  the  full  capabilities  of  the  CODE 
concept,  as  proposed  by  Stytz,  et  al.  (34). 

4.3  Knowledge  Representations 

The  DMTITE  software  architecture  is  ultimately  responsible  for  providing  the  data 
structures  and  implementations  of  the  knowledge  representations  identified  by  the  design 
methodology.  This  responsibility  is  best  addressed  by  applying  software  engineering  prin¬ 
ciples  to  the  problem,  as  discussed  in  the  following  subsections. 
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4.3.1  Knowledge  Expressions.  As  discussed  in  section  3.2.1,  a  general  knowledge 
representation  based  on  if-then-else  predicates  is  required  to  support  the  various  infer- 
encing  strategies  to  be  used.  This  representation  must  be  extensible  to  support  featinres 
of  one  inferencing  strategy  not  available  (or  known)  to  another,  while  residing  in  a  com¬ 
mon  repository.  Fortunately,  the  object-oriented  concept  of  inheritance  supports  these 
requirements. 

The  DMTITE  software  architecture  defines  a  generic  Expression  class  from  which  all 
knowledge  expressions  are  derived.  The  Expression  class  is  piurely  virtual;  it  establishes 
the  access  methods  to  be  supported  by  eJl  derived  types,  but  can’t  be  used  to  directly 
instantiate  a  knowledge  expression.  The  current  format  for  the  knowledge  expressions 
used  for  case-based,  rule-based,  and  fuzzy  logic  inferencing  in  DMTITE  is  discussed  in 
Appendix  C. 

4.3.2  Policies.  The  software  architecture  directly  maps  the  concept  of  policies 
(discussed  in  section  3.2.2)  to  a  data  structure.  As  with  knowledge  expressions,  policies 
may  encapsulate  information  in  one  inferencing  strategy  that  is  neither  known  or  required 
by  another.  In  much  the  same  manner  as  was  done  for  expressions,  a  piurely  virtual  Policy 
class  is  defined  from  which  policies  specific  to  each  of  the  inferencing  strategies  are  derived. 
Unlike  the  Expression  class,  which  doesn’t  define  the  contents  of  derived  expressions,  the 
Policy  class  forces  all  derived  policies  to  initially  view  the  expressions  in  a  generic  sense, 
casting  them  to  the  appropriate  derived  type  internally.  More  information  on  the  case- 
based,  rule-based,  and  fuzzy  logic  policy  classes  can  be  found  in  Appendix  C. 

4.3.3  Knowledge  Bases.  At  this  level  of  abstraction,  the  software  architecture 
departs  from  the  design  methodology.  From  the  methodology  viewpoint,  a  knowledge  base 
is  comprised  of  all  knowledge  in  its  constituent  policies.  From  the  architectural  viewpoint, 
a  knowledge  base  relies  on  the  policies  to  define  its  constituent  knowledge.  In  other  words, 
the  knowledge  base  class  contains  a  list  of  policies  to  be  referenced  and  the  methods  to 
access  those  policies.  However,  inferencing  engines  aren’t  aware  of  this  distinction;  they 
access  the  knowledge  bases  as  if  the  knowledge  resided  within  them. 
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4-3.4  Knowledge  Base  Repository.  The  software  architecture  views  the  knowledge 
base  repository  as  a  collection  of  policies  (where  the  actual  knowledge  expressions  reside) 
and  knowledge  bases.  Policies  are  not  directly  accessible  to  users  of  the  repository;  instead, 
the  repository  forces  users  to  view  knowledge  at  the  knowledge  base  level. 

4.3.5  Type-Independent  Variables.  One  aspect  of  knowledge  expressions  not 
addressed  by  the  design  methodology  involves  variable  storage.  Variables  of  diiferent  types 
require  different  2imounts  of  memory,  so  a  means  of  abstracting  this  detail  away  is  necessary. 
Again,  inheritance  comes  into  play. 

The  software  architectm'e  implements  a  type-independent  variable  class.  This  class 
requires  the  user  to  specify  the  type  of  data  being  stored  initially,  as  well  as  forcing  the 
user  to  explicitly  retrieve  the  value,  but  does  allow  knowledge  expressions  to  store  this 
information.  Methods  are  provided  to  evaluate  relationships  (e.g.,  “less  than”,  “greater 
than”)  between  variables,  and  mathematical  expressions  can  be  embedded  and  evaluated 
within  a  variable.  The  impact  of  this  design  decision  is  that  a  small  amount  of  additional 
processing  time  is  required  to  evaluate  an  expression  and  additional  information  must  be 
embedded  in  each  expression  (see  Appendix  C);  however,  the  flexibility  provided  by  this 
approach  far  outweighs  the  costs. 

4.4  Simulating  Human  Behaviors:  The  Entity  Profile 

As  stated  in  section  4.2.2,  the  Arbitration  Engine  mauntains  an  “entity  proflle”  in 
support  of  multiple  skill  levels.  The  flrst  component  of  the  entity  proflle  is  the  skills  vector, 
part  of  the  general  architecture  proposed  by  Santos,  et  al.  (27)  This  vector  is  supplemented 
by  entity  traits — variables  deflned  for  all  CGFs  (regardless  of  their  domain)  and  used  to 
support  a  combat  psychology  model.  When  combined,  these  concepts  address  behavior 
consistency,  unpredictability,  and  certifiability. 

4.4.  i  Skills  Vector.  A  CGF  skills  vector  is  a  hierarchical  collection  of  parameters 
representing  the  current  skill  level  of  the  CGF  in  question.  Highly  specialized  skills  are 
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mapped  to  more  basic  skills,  both  of  which  may  ch2inge  over  time.  This  interaction  between 
skills  guarantees  consistency  in  the  behavior  and  performance  of  the  CGF  (27). 

The  skills  vector  is  a  domdn-independent  concept  with  domain-specific  instantia¬ 
tions.  While  a  skill  may  be  shared  among  different  CGF  categories,  no  skill  will  be  common 
to  all  categories.  As  a  result,  the  DMTITE  software  architecture  only  defines  the  skills 
vector  as  an  object  and  makes  no  attempt  to  define  its  contents.  Instead,  the  skills  to  be 
used  by  a  CGF  are  defined  at  runtime  via  an  initialization  file  (see  Appendix  E). 

4-4-^  Entity  Traits.  Human  behaviors  in  combat  aren’t  strictly  a  measme  of  skill; 
they  reflect  other,  less  tangible  concepts.  Unlike  skills,  these  concepts  (or  traits)  apply  to  all 
combatants,  albeit  in  varying  degrees  due  to  genetics  cind  life  experience  (29).  When  used  in 
conjimction  with  a  combat  psychology  model,  these  variables  address  the  unpredictability 
and  certifiability  concerns  of  CGF  behavior  by  modifying  the  CGF’s  behavior  not  only 
in  response  to  that  entity’s  skills,  but  also  its  evaluation  of  the  current  environment.  For 
example,  consider  two  CGFs  that  have  identical  skill  vectors  (i.e.,  they  are  equedly  skilled 
and  seemingly  identical).  If  the  CGFs  traits  are  not  considered,  these  CGFs  will  respond 
identically  to  the  same  input — revealing  a  predictable  pattern  that  can  be  exploited  by 
human  actors.  Introducing  traits  quantifies  the  less  tangible  attributes  of  these  CGFs, 
and  allows  (for  example)  one  CGF  to  hesistate  in  a  given  situation  while  the  other  CGF 
does  not.  Although  two  CGFs  with  identical  skills  vectors  and  traits  will  display  the 
same  behavior  in  a  given  situation,  the  addition  of  these  extra  veiriables  makes  exploitable 
patterns  more  difficult  to  discern. 

4.4-3  Combat  Psychology  Model.  If  human  behaviors  are  to  be  simulated,  then 
hmnan  behaviors  under  combat  situations  must  be  incorporated  into  the  entity  profile. 
Current  CGFs  tend  to  “fight  to  the  last  man”  with  little  or  no  effect  on  their  performance, 
forcing  human  controllers  to  order  heavily  damaged  CGFs  to  retreat  (18).  These  behaviors 
imdermine  the  unpredictability  of  CGFs,  since  they  establish  patterns  of  behavior  that 
can  be  exploited  by  human  actors.  Furthermore,  these  behaviors  aren’t  certifiable  since 
even  highly  trained  combatants  suffer  performance  degradation  imder  harsh  battlefield 
conditions. 
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Incorporating  a  combat  psychology  model  in  the  architecture  Eiddresses  these  con¬ 
cerns.  CGFs  operating  under  such  a  model  can  suffer  progressively  increasing  performance 
degradations,  from  slight  hesitations  to  panic-stricken  retreat.  The  combat  psychology 
model  incorporates  multiple  levels  of  behaviors  in  a  manner  identical  to  how  the  skills  vec¬ 
tor  supports  multiple  skill  levels.  Therefore,  the  combat  psychology  model  also  supports 
consistent  CGF  behaviors,  since  a  given  CGF  “psychological  profile”  displays  behaviors 
consistent  to  those  displayed  by  a  human  combatant  with  a  similar  psychological  makeup. 
The  combat  psychology  model  used  in  the  DMTITE  is  discussed  in  detail  in  Appendix  D. 

4-5  Bringing  It  All  Together:  The  DMTITE  Entity  Design 

The  concepts  and  components  discussed  in  the  previous  sections  are  brought  together 
in  the  initial  DMTITE  software  design  (Figure  4.4). 

This  object  TOode/ represents  the  structural  aspects  of  a  DMTITE  entity,  establishing 
the  objects  and  the  relationships  between  objects  that  comprise  the  DMTITE  software 
architecture.  Objects  that  share  common  structure  and  behavior  (i.e.,  decision  engines) 
are  represented  hierarchically.  Since  the  structmre  of  a  DMTITE  entity  is  defined  by  this 
architecture,  software  engineers  can  implement  decision  engines  to  support  specific  infer- 
encing  strategies  without  concern  as  to  how  the  engine  will  be  invoked — the  processing  fiow 
already  addresses  this  concern.  Additionally,  existing  physical  models  can  be  incorporated 
into  DMTITE  by  simply  ensuring  each  uses  the  interface  defined  by  the  object  model.  As¬ 
suming  the  existing  physic£j  model  is  itself  modular  in  design,  little  (if  any)  modification 
will  be  required  to  the  model  itself. 

The  object  model  also  incorporates  many  domain-independent  concerns  while  not 
explicitly  declaring  them.  For  instance,  the  entity  profile  is  itself  nothing  more  than  a 
collection  of  V2iriables  used  by  the  Arbitration  Engine.  This  engine  is  derived  from  a  generic 
Decision  Engine  object,  which  already  includes  a  set  of  variables.  As  a  result,  the  entity 
profile  is  subjected  to  abstraction',  as  an  architectural  component  it  is  tmimportant  amd 
therefore  suppressed.  This  allows  knowledge  engineers  to  identify  and  software  engineers 
to  implement  the  entity  profile  as  nothing  more  than  a  list  of  variables.  The  architecture 
handles  these  variables  no  differently  than  any  other. 
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Figure  4.4  DMTITE  Entity  Design 

Finally,  the  object  model  defines  how  state  information  is  passed  throughout  a 
DMTITE  entity.  The  CRC  can  not  “go  outside”  this  model  to  obtEiin  information  directly 
from  the  distributed  virtual  environment.  This  is  because  the  Cognitive  Representation 
Component  object  is  physically  isolated  from  the  Sensor  Interface  object.  On  the  other 
hand,  the  architecture  allows  physical  models  to  retrieve  state  information  from  or  pass 
state  information  to  either  of  the  state  information  repositories  (the  Sensor  Interface  and 
the  Physical  State  Information  Interface).  Furthermore,  since  the  only  difference  between 
the  two  repositories  is  the  “fiavor”  of  information  each  contains,  the  object  model  provides 
one  set  of  methods  for  both.  This  allows  softweure  engineers  to  modify  how  either  decision 
engines  or  physic2il  models  send  and  receive  information  without  requiring  them  to  learn 
two  different  sets  of  methods. 

In  short,  the  DMTITE  object  model  allows  both  knowledge  and  software  engineers  to 
implement  CGFs  without  concern  to  the  tmderlying  architecture.  Assuming  the  required 
physical  models  have  been  previously  incorporated  into  DMTITE,  new  CGFs  cein  be  im- 
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plemented  solely  by  identifying  the  knowledge  required  and  how  that  knowledge  is  invoked. 
If  a  physical  model  is  required  that  hasn’t  been  previously  implemented  in  DMTITE,  only 
minimal  interaction  with  the  software  architecture  is  required. 
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V.  Contributions  and  Recommendations 


5.1  Contributions 

The  design  methodology  and  software  architecture  developed  during  the  course  of 
this  research  contribute  to  future  CGF  development  efforts  in  many  ways.  The  domain- 
independent  nature  of  the  design  methodology  allows  it  to  be  used  not  only  during  the 
development  of  DMTITE  CGFs,  but  also  for  other  CGF  development  efforts.  Knowledge 
engineers  can  incorporate  new  knowledge  acquisition  tools  and  techniques  in  the  method¬ 
ology  as  they  become  available.  Software  engineers  can  develop  models  to  reflect  evolving 
weapon  systems,  or  new  decision  engines  to  address  various  inferencing  strategies,  without 
detracting  from  the  overall  methodology.  The  extended  general  architecture  has  been  im¬ 
plemented  using  accepted  software  engineering  techniques.  This  research  has  blurred  the 
line  between  the  circhitecture  (a  series  of  black  boxes  that  deflne  what  processing  must  be 
done)  and  the  software  design  (which  defines  how  the  black  boxes  accomplish  their  tasks). 
Knowledge  engineers  can  add  knowledge  to  this  architecture  and  gauge  the  effects  of  their 
additions  without  knowledge  of  the  underlying  software  architecture.  Software  engineers 
can  implement  customized  black  boxes  with  no  concern  as  to  how  the  rest  of  the  soft¬ 
ware  design  performs  it  tasks.  As  a  result,  CGF  development  efforts  can  focus  on  what 
knowledge  is  required  and  how  that  knowledge  is  invoked. 

Another  contribution  of  this  reseeurch  is  the  separation  of  domain-dependent  issues 
from  domain-independent  issues.  Domain-independent  issues  such  as  coordination  and 
communication  between  CGFs  can  be  implemented  within  the  architectiu:e  eind  software 
design.  A  standardized  architectmre  for  broad  classes  of  CGFs  makes  the  incorporation  of 
such  issues  readily  available  to  all  CGFs  using  that  architecture.  Ultimately,  these  CGFs 
can  display  more  complex  behaviors  (e.g.,  combined  arms  tactics)  than  behaviors  displayed 
by  CGFs  based  on  tightly-coupled  software  architectures.  Perhaps  more  importantly,  the 
amoimt  of  effort  required  to  implement  complicated  behaviors  is  greatly  reduced. 

Finally,  this  research  maps  the  xmpredictability  and  certifiability  of  CGF  behaviors 
to  both  skills  and  a  psychological  model.  Since  combat  is  not  just  a  function  of  skills, 
believable  CGF  behaviors  require  the  injection  of  additional,  less  tangible  concepts  such 
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as  morale,  aggressiveness,  and  intra-team  support  into  the  training  environment.  These 
concepts  allow  two  seemingly  identical  CGFs  to  display  different  behaviors  based  on  their 
current  state  as  well  as  the  state  of  the  environment.  This  yields  a  time-limited  Turing 
test  for  human  actors  in  distributed  virtual  environments — given  the  short  response  time 
in  such  an  environment,  human  actors  can’t  distinguish  between  CGFs  and  other  human 
actors.  As  a  result,  human  actors  are  forced  to  engage  CGFs  as  they  would  other  human 
actors,  reinforcing  realistic  tactics  and  increasing  the  overall  training  effectiveness. 

5.2  Recommendations 

There  remains  much  that  can  be  further  explored  with  respect  to  this  research  effort, 
both  in  concept  and  in  application.  With  the  establishment  of  a  design  methodology  and 
a  supporting  software  architectme,  most  of  these  research  areas  are  concentrated  in  the 
field  of  artificial  intelligence. 

5.2.1  CGF  Coordination.  While  the  DMTITE  software  architecture  was  devel¬ 
oped  with  an  eye  towards  CGF  coordination  and  communication,  no  method  in  support 
of  this  goal  was  identified  or  implemented.  This  aspect  of  CGFs  has  a  broad  scope,  nec- 
esseirily  addressing  other  concerns  such  as  mission  planning  and  achievement — concerns 
that  fall  within  the  domains  of  both  the  Long-Term  and  Mission-Level  Decision  Engines. 
Furthermore,  a  means  of  communicating  concepts  such  as  those  identified  by  the  combat 
psychology  model  is  required  to  utilize  the  full  range  of  behaviors  supported  by  the  model. 

5.2.2  Planning.  Planning  is  current  a  “hot”  topic  in  the  field  of  artificial  in¬ 
telligence  and,  while  the  software  architectme’s  concept  of  a  long-term  decision  engine 
implicitly  supports  this  topic,  no  explicit  support  is  provided.  Real-time  mission  planning 
for  CGFs  remains  just  beyond  the  reach  of  researchers.  A  'priori  mission  planning  tech¬ 
niques  have  been  identified,  but  fail  to  adequately  address  the  dynamic  nature  of  DVEs 
such  as  the  synthetic  battlespace. 

5.2.3  Knowledge  Acquisition.  One  of  the  more  obvious  assumptions  of  this  re¬ 
search  is  that  no  one  knowledge  acquisition  technique  is  “most  suitable”  for  CGF  develop- 
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ment.  However,  no  attempt  was  made  to  validate  this  assumption  since  it  was  out  of  scope 
of  this  effort.  Future  research  in  knowledge  acquisition  could  attempt  to  either  validate  this 
assumption  or  invalidate  it  by  identifying  an  acquisition  technique  suitable  for  the  broad 
classes  of  CGFs  supported  by  the  DMTITE  design  methodology  and  software  architectmre. 
Even  if  this  assumption  is  validated,  it  may  be  possible  to  identify  knowledge  acquisition 
methods  that  are  more  applicable  than  others  in  the  domain  of  CGF  construction. 

5.2.4  Verification  and  Validation.  Another  obvious  assumption  of  this  research 
is  the  behaviors  of  DMTITE  CGFs  can  be  verified  and  validated.  In  past  efforts,  this  has 
essentially  meant  sitting  domain  experts  in  firont  of  a  terminal  and  having  them  say  “yeah, 
that  looks  right.”  When  CGFs  display  multiple  skill  levels,  this  qualitative  approach  works 
only  if  the  domain  experts  can  relate  to  the  skill  level  being  displayed.  Future  research 
could  attempt  to  quantify  the  verification  and  validation  of  CGF  behaviors.  Such  research 
would  be  extensible  to  other  CGF  development  efforts  as  well. 

5.3  Conclusions 

A  domedn-independent  design  methodology  and  software  architecture  address  many 
of  the  concerns  raised  by  ciurent  CGF  development  efforts.  By  establishing  a  common 
framework  from  which  CGFs  belonging  to  various  domains  can  be  constructed,  develop¬ 
ment  (and  ultimately  training)  costs  are  reduced.  CGFs  within  a  given  domeiin  can  exploit 
commonalities  shared  by  other  CGFs  within  that  domain.  Domain-independent  concepts 
such  as  combat  behaviors  and  skills  can  be  implemented  for  all  CGFs,  not  just  those  in 
a  specific  domain.  The  software  architecttu:e  removes  the  threat  generation  system  from 
a  single  simulator  and  m^lkes  it  globally  accessing  to  all  simulators  within  a  distributed 
virturJ  environment.  This  riUows  all  simxilators  to  observe  threat  behaviors  at  a  consistent 
fidelity  level.  CGFs  built  firom  a  common  architecture  inherit  the  domain-independent  fea¬ 
tures  of  that  architecture.  This  inheritrince  allows  CGFs  to  form  a  complex,  coordinated 
threat  environment.  In  addition,  the  domain-independent  concepts  of  skills  and  combat 
psychology  minimize  exploitable  patterns  of  CGF  behavior,  increasing  the  overall  training 
effectiveness  of  the  distributed  virturd  environment. 
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Wliile  this  research  was  conducted  in  support  of  a  training  environment  for  human 
pilots,  the  resulting  design  methodology  and  software  architecture  are  easily  adaptable  to 
other  CGF  development  efforts.  This  is  because  neither  the  methodology  nor  the  2irchi- 
tecture  are  coupled  to  a  specific  domain  (air,  land,  surface,  or  space).  In  addition,  the 
methodology  isn’t  bound  to  a  specific  set  of  knowledge  acquisition,  verification,  or  vali¬ 
dation  tools;  it  allows  knowledge  engineers  to  use  any  method  they  deem  appropriate  to 
their  specific  development  effort.  Nor  is  the  software  architecture  bound  to  a  specific  set 
of  physical  models — software  engineers  may  develop  additional  models  as  necessary  and 
easily  incorporate  them  into  the  overall  software  design.  This  shifts  the  CGF  development 
effort  away  from  “structure  implementation”  and  towards  “knowledge  implementation.” 

Despite  these  assertions,  the  ultimate  success  of  this  research  can  be  gauged  by  how 
widely  accepted  and  used  the  methodology  and  architecture  are.  Applying  this  approach 
strictly  within  the  dommn  of  DMTITE  without  evaluating  its  fitness  for  other  CGF  de¬ 
velopment  efforts  will  not  not  prove  anything.  Successfully  implementing  CGFs  using  this 
methodology  and  architecture  in  other  development  efforts  is  critical  for  this  research  to 
be  validated. 
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Appendix  A.  Common  Object  Database  Architecture  Implementation 

The  CODE  architectiire  implemented  for  the  DMTITE  project  is  a  significant  modification 
of  previous  CODE  implementations.  The  exact  implementation,  as  well  as  the  ramifications 
of  these  modifications,  is  discussed  in  the  following  sections. 

A.l  Previous  CODE  Implementations 

There  have  been  two  previous  versions  of  the  CODE,  one  developed  in  support  of  the 
Virtual  Cockpit  project  (1),  the  other  in  support  of  the  Intelligent  Wingman  project  (38). 
The  initial  version  of  the  CODE  was  built  using  the  assumption  that  only  a  single  appli¬ 
cation  per  host  would  use  the  CODE.  While  this  supported  data  sharing  across  a  network, 
it  greatly  reduced  the  number  of  entities  supported  by  the  CODE  concept.  A  modification 
was  made  to  support  multiple  processes  on  a  single  host;  however,  these  processes  had 
to  be  spawned  from  the  same  parent  process  (38).  This  implementation  falls  short  of  the 
functionality  required  by  the  DMTITE  project,  in  which  CGFs  are  viewed  as  independent 
processes,  not  child  processes  of  a  single  parent. 

The  two  implementations  also  shared  a  set  of  problems  making  both  undesirable 
for  supporting  DMTITE.  Neither  coiild  support  multiple  CODEs  on  a  single  host;  in 
f2ict,  it  could  be  demonstrated  that  bringing  up  a  second  CODE  would  cause  the  host 
to  crash.  Neither  implementation  allowed  for  “selective”  retrieval  of  the  contents  of  a 
container;  the  application  either  retrieved  the  contents  of  the  entire  container  or  nothing 
at  edl.  Finally,  both  implementations  allowed  applications  to  directly  access  the  CODE 
memory  contents.  This  dangerous  access  technique  not  only  allowed  the  application  to 
access  its  assigned  memory  segment  within  the  CODE,  but  any  other  memory  segment  as 
well.  Clearly,  modifications  were  required  to  bring  the  CODE  implementation  to  the  level 
of  functionality  support  by  its  concept  and  required  by  DMTITE. 

A. 2  Extending  the  CODE  Concept 

While  previous  implementations  of  the  CODE  failed  to  meet  the  original  concept, 
the  original  concept  did  not  adequately  address  issues  germane  to  the  DMTITE  effort.  To 
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support  the  operational  concept  of  the  synthetic  battlespace,  containers  must  be  able  to 
distinguish  between  and  properly  handle  persistent  and  non-persistent  information.  Fur¬ 
thermore,  the  original  CODE  concept  envisioned  a  single  type  of  “user” — an  application 
concerned  with  the  information  in  the  CODE.  However,  an  implicit  reqmrement  of  the 
CODE  was  that  it  be  “recursively  defined”;  on  a  single  host,  tightly-scoped  CODEs  could 
be  connected  to  larger  CODEs  and  so  forth,  ending  with  a  CODE  contEiining  the  totality 
of  the  DVE  (Figure  A.l).  In  order  to  support  this  concept,  a  new  “user”  was  required — one 
that  viewed  the  information  in  the  CODE  only  with  regards  to  routing.  These  concerns 
are  addressed  in  the  DMTITE  implementation  of  the  CODE. 
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Distributed  Virtual  Environmnt 

Figme  A.l  “Recmsively  Defined”  CODE  System 

A. 2.1  Persistent  and  Non-Persistent  Containers.  There  are  actually  two  types  of 
containers  being  handled  by  the  CODE.  The  information  in  persistent  containers  is  accessed 
one  or  many  times  by  the  applications  coimected  to  the  CODE.  Persistent  containers  can 
be  updated;  however,  all  information  in  the  container  remains  available  to  the  applications 
accessing  it.  On  the  other  hand,  the  information  in  non-persistent  containers  is  meant  to 
be  accessed  at  most  once  by  each  application;  when  all  applications  have  accessed  specific 
information,  that  information  is  removed  from  the  container.  Non-persistent  containers 
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can  be  updated;  however,  only  that  information  not  accessed  previously  by  an  application 
is  available. 

This  distinction  is  made  to  support  the  two  types  of  information  broadcast  in  a 
distributed  environment.  Data  is  persistent  information — for  example,  entity  state  infor¬ 
mation.  If  an  entity  doesn’t  move,  its  current  position  remains  known  to  other  entities. 
Only  when  the  entity  “leaves”  the  distributed  environment  is  its  information  removed. 
Events  axe  non-persistent  data.  An  entity  affected  by  a  missile  detonation  should  process 
this  information  once  and  ignore  any  duplicate  notifications  of  the  same  event.  Therefore, 
event  information  should  be  removed  once  all  affected  entities  have  received  it. 

The  DMTITE  CODE  implementation  processes  these  two  types  of  containers  by 
monitoring  the  number  of  readers  for  eeich  container  as  well  as  the  identity  of  each  reader. 
Non-persistent  information  is  passed  only  once  to  each  reader;  however,  that  information 
remains  available  imtil  all  readers  have  accessed  it.  The  CODE  removes  non-persistent 
information  from  a  container  only  after  it  detects  all  readers  have  accessed  the  container. 
Persistent  containers  are  monitored  as  weU,  but  no  action  is  taken  when  all  readers  have 
accessed  these  containers. 

A. 2. 2  “Pass-Through”  Applications.  There  axe  actually  two  views  of  CODEs 
within  a  “recursively  defined”  CODE  system.  A  subordinate  CODE  contmns  a  strict 
subset  of  the  information  in  the  supervisory  CODE  to  which  it  is  logically  attached.  In 
turn,  a  supervisory  CODE  can  be  subordinate  to  einother,  more  inclusive  CODE.  This 
chEun  of  subordinate/supervisory  CODEs  ends  with  the  World  State  Manager’s  CODE; 
since  it  contains  the  total  state  of  the  DVE,  it  ceinnot  be  subordinate  to  any  other  CODE. 

The  origin2J  CODE  is  nothing  more  than  a  data  repository  for  use  by  other  appli¬ 
cations  and  is  incapable  of  supporting  this  concept.  A  CODE  is  not  concerned  with  the 
type  of  information  cont^lined  within  it,  nor  does  it  initiate  a  connection  with  the  source  of 
that  information.  Therefore,  a  new  type  of  CODE  “user”,  an  object  manager,  is  required 
to  transfer  containers  between  CODEs  in  an  intelligent  manner. 

As  implemented  for  DMTITE,  ein  object  manager  is  initialized  (via  an  initi2Jization 
file)  with  the  type  of  information  to  be  passed  to  its  subordinate  CODE  as  well  as  how 
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often  the  information  is  to  be  updated.  At  the  specified  intervals,  the  object  manager 
activates,  passes  the  information  matching  its  criteria  to  the  subordinate  CODE,  and 
passing  all  new  information  from  the  subordinate  CODE  to  the  supervisory  CODE.  Each 
object  manager  must  be  terminated  externally;  however,  object  managers  detect  these 
signals  and  disconnect  from  any  CODEs  they  access.  This  is  necessary  since  each  CODE 
releases  its  disk  space  only  after  all  connections  to  it  have  been  terminated. 

A. 3  CODE  Logical  View  vs.  CODE  Implementation  View 

Even  with  the  extended  CODE  concept,  there  remains  a  difference  between  how  the 
CODE  logically  operates  and  how  its  implementation  operates.  These  two  views  are  briefiy 
discussed  below,  along  with  the  justification  for  the  differences  between  the  two. 

A. 3.1  Logical  View.  Prom  a  logical  viewpoint,  an  application  views  the  CODE  as 
a  collection  of  containers  from  which  information  is  extracted  and  to  which  information  is 
written  (Figure  A.2).  The  order  in  which  information  is  placed  within  a  container  remains 
constant:  an  application  writes  its  own  information  to  its  assigned  slot,  and  can  read 
information  from  another  application  by  accessing  that  application’s  assigned  slot.  In  this 
view,  applications  always  obtain  the  most  up-to-date  information  eeich  time  a  container  is 
read. 


Figure  A.2  Logic2il  View  of  a  CODE 

A. 3. 2  Implementation  View.  As  implemented,  a  CODE  consists  of  two  uni¬ 
directional  halves  (Figure  A.3).  Prom  the  viewpoint  of  an  application  attached  to  the 
CODE,  one  half  consists  of  “incoming”  containers — information  to  be  used  by  the  applica¬ 
tions  attached  to  the  CODE.  The  other  half  consists  of  “outgoing”  containers — information 
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generated  by  the  applications  connected  to  the  CODE.  Therefore,  most  applications  may 
only  read  “incoming”  containers  and  may  only  write  “outgoing”  containers.  Although  it 
is  desirable  to  allow  applications  to  retrieve  the  most  up-to-date  information  from  “outgo¬ 
ing”  contcdners,  the  decision  to  disallow  this  was  made  to  simplify  processing  within  the 
CODE.  As  a  result  of  this  decision,  processing  time  is  decreased  since  updated  (“outgo¬ 
ing”)  information  can  be  retrieved  and  forwarded  without  scanning  the  entire  contents  of 
the  respective  container. 


CODB 


Figure  A.3  Implementation  View  of  a  CODE 


A.4  DMTITE  CODB  Object  Model 

The  DMTITE  CODE  object  model  that  supports  the  extended  CODE  concept  is 
shown  in  Figure  A.4.  As  established  by  Rumbaugh  (26),  rectangles  denote  classes  and 
subclasses,  while  triangles  are  used  to  indicate  inheritance.  There  eire  four  classes  within 
the  CODE  object  model,  as  described  below;  one  is  a  virtual  base  class,  while  the  others 
represent  the  ways  an  application  can  “view”  the  CODE. 


Figure  A.4  DMTITE  CODE  Object  Model 
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A.4-1  Common  Object  Database.  The  Common  Object  Database  class  is  the 
virtual  base  class  for  all  CODE  implementations.  This  class  defines  the  implementation 
of  some  member  functions  inherited  by  derived  classes;  however,  it  defines  the  interface 
for  most  member  functions  (leaving  the  derived  classes  to  instantiate  their  own  versions 
of  these  functions).  Because  this  class  forces  derived  classes  to  define  their  own  version  of 
some  member  functions,  no  CODE  of  this  type  can  be  directly  instantiated. 

A.4.2  User.CODB.  The  User.CODB  is  the  CODE  as  viewed  by  an  application 
concerned  with  the  contents  of  the  CODE.  This  CODE  object  assigns  a  single  slot  in 
each  container  to  be  written  to  by  an  application  (in  direct  support  of  the  original  CODE 
concept).  Unlike  previous  CODE  implementations,  applications  never  directly  access  this 
memory  “slot” .  Instead,  the  underlying  data  structure  within  the  CODE  is  responsible  for 
determining  where  to  place  incoming  information  in  the  shared  memory  arena.  Applica¬ 
tions  connected  to  a  User.CODB  may  only  read  incoming  containers  and  may  only  write 
outgoing  containers. 

A.4-S  Sub.CODB.  This  subclass  is  how  the  object  managers  view  the  CODE 
to  which  they  are  subordinate.  This  view  of  the  CODE  is  similar  (but  not  identical)  to 
the  view  applications  have  of  the  User.CODB.  As  a  result,  the  Sub.CODB  is  derived  from 
the  User.CODB  class.  Object  managers  may  only  read  incoming  messages  from  aind  write 
outgoing  messages  to  the  CODE  to  which  they’re  subordinate.  However,  since  object 
managers  are  responsible  for  passing  along  information  from  multiple  applications,  they’re 
allowed  to  write  to  multiple  slots  within  the  Sub.CODB. 

A.4.4  Super.CODB.  This  subclass  is  how  the  object  managers  view  the  CODE 
they  supervise.  In  this  view,  the  role  of  “incoming”  and  “outgoing”  containers  is  reversed; 
the  object  mamager  reads  “outgoing”  containers  and  writes  “incoming”  containers.  As  with 
the  Sub.CODB,  object  managers  aire  allowed  to  multiple  slots  within  containers,  since  they 
axe  passing  along  information  from  miiltiple  (possibly  distributed)  applications. 
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A. 5  CODE  Implementation 

The  actual  implementation  is  mapped  directly  from  the  extended  CODE  concept, 
taking  the  implementation  viewpoint  discussed  in  section  A.3.2.  IRIX  shared  memory 
arenas  and  Steindard  Template  Library  (STL)  data  structures  were  used  to  implement  the 
interprocess  communication  emd  storage  functionality  aspects  respectively.  These  changes 
also  required  the  CODE  container  data  structures  to  be  re-engineered. 

For  DMTITE,  the  contents  of  the  containers  were  also  implemented  as  classes.  How¬ 
ever,  this  aspect  of  the  implementation  does  not  directly  affect  the  CODE  implementation 
(although  it  is  related  to  it)  and  is  not  discussed  here. 

A.5.1  Shared  Memory  Arenas.  Under  UNIX,  the  size  of  shared  memory  is  nor¬ 
mally  limited  to  64  KE.  Silicon  Graphics  (SGI)  addresses  this  limitation  in  their  IRIX 
operating  system  through  the  use  of  shared  memory  arenas.  An  arena  is  a  disk  file  that 
acts  as  additional  shared  memory  (28).  This  interprocess  communication  mechanism  is  im¬ 
plemented  as  extended  functions  in  the  C  library,  operating  in  user  space  without  system 
calls.  While  this  is  convenient  from  a  programming  perspective,  these  arenas  are  IRIX- 
specific.  As  a  residt,  this  implementation  of  the  CODE  is  not  portable  to  other  hardware 
platform  or  even  SGI  machines  using  another  operating  system.  If  the  CODE  is  to  be 
implemented  on  einother  platform,  the  interprocess  communication  aspects  will  need  to  be 
re-engineered. 

A.5.S  Maps  and  Vectors:  The  Standard  Template  Library.  The  DMTITE  CODE 
implementation  relies  heavily  on  the  Standard  Template  Library  (STL)  map  and  vector 
classes.  The  STL  is  a  collection  of  commonly-used  data  structures,  defined  as  templates 
so  they  are  usable  by  any  data  type  (even  user-defined).  The  imderlying  structure  of  the 
STL  is  based  on  red-bleick  trees,  guaranteeing  0(lg  n)  access  time  in  the  worst  case  (9). 
In  2iddition,  STL  handles  memory  allocation  and  deallocation  automatically.  Finally,  the 
STL  has  become  part  of  the  ANSI  standeird  for  C-b-f-,  which  allows  the  storage  aspects  of 
this  CODE  implementation  to  be  portable  across  hardware  platforms. 
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In  STL,  a  map  defines  a  relationship  between  a  key  and  its  satellite  data,  in  a  manner 
similar  to  how  a  telephone  book  maps  a  name  to  a  number  (2).  A  map  is  simil^u:  to  an 
array  in  that  the  satellite  data  can  be  accessed  using  the  key  as  an  index.  When  a  new 
index  is  referenced,  the  map  dynamically  allocates  the  appropriate  amount  of  memory 
for  the  satellite  data.  Each  index  in  a  map  is  unique;  therefore,  when  an  existing  index 
is  referenced  the  map  overwrites  the  associated  satellite  data  as  appropriate.  A  vector, 
on  the  other  hand,  is  a  linear  list  of  fiexible  size.  For  vectors,  the  user  explicitly  places 
information  at  the  head  or  tail  of  the  vector — ^no  indexing  is  supported.  In  the  worst  case, 
then,  the  entire  vector  must  be  searched  to  find  a  specific  piece  of  data. 

In  the  CODE,  maps  are  used  within  the  shared  memory  arena  to  map  slots  to  actual 
memory  locations.  In  addition,  these  maps  are  stored  in  a  “map  of  maps”  which  allows 
applications  to  locate  and  access  a  specific  memory  slot  in  0(lg  n)  time.  To  support  the 
CODE  concept  of  double-buffering,  two  such  “map  of  maps”  are  instantiated:  one  for 
incoming  containers,  one  for  outgoing  containers.  (For  additional  information  on  double¬ 
buffering,  refer  to  Stytz,  et  al.  (34)  or  Zvurita  (38).)  Vectors  are  used  for  lower-level  data 
structures  in  which  each  element  will  most  likely  be  accessed  sequentially.  Although  these 
data  structures  are  not  discussed  here,  they  are  part  of  the  CODE.  Therefore,  the  concept 
of  vectors  is  included  here  for  completeness. 

A.5.3  Containers.  As  proposed  by  Stjd;z,  et  eJ.,  a  CODE  container  is  divided  into 
categories  and  slots,  as  shown  in  Figure  A.5.  The  primary  category  is  the  coarsest  division 
of  container;  an  example  of  a  primary  category  in  DMTITE  would  be  “red  force”,  “blue 
force”,  “neutral  forces”,  and  “unknown  forces”.  A  primary  category  is  further  divided 
into  secondary  categories,  which  are  divided  into  tertiary  categories,  and  finally  specific 
categories  (the  smallest  possible  division  of  a  CODE  container).  Slots  contain  the  actual 
data  of  the  container;  slot  contents  are  provided  by  applications,  not  the  CODE. 

An  application  manipulates  a  container  as  a  collection  slots,  each  of  which  is  a  data 
structure  shown  in  Figure  A.6.  The  first  six  fields  of  this  data  structmre  map  the  slot  to 
a  particular  container  location;  the  last  field  contains  the  actual  data.  The  container  ID 
field  indicates  the  container  to  which  the  data  is  assigned,  while  the  entity  ID  field  contains 
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Figvire  A.5  CODE  Container  Anatomy 

a  simulation-unique  identifier  for  the  application  to  which  the  information  pertains.  This 
ID  may  be  the  application  that  originally  broadcast  the  information  to  the  DVE  (e.g., 
entity  state  information),  or  the  application  targeted  by  the  information  (e.g.,  a  fire  or 
collision  event).  The  remaining  four  fields  are  the  categories  relevant  to  the  information; 
each  category  is  represented  as  a  32-bit  value,  allowing  a  total  of  32  unique  identifiers 
per  category.  (The  choice  of  four  categories  was  strictly  arbitrary;  the  actual  number  can 
be  increased  or  decreased  by  modifying  the  corresponding  data  structure.)  “Wildcard” 
categories  are  permitted,  allowing  a  slot  to  correspond  to  any  value  of  the  category  in 
question. 

A .  6  Ramifications 

This  CODE  implementation  addresses  the  shortcoming  identified  with  previous  im¬ 
plementations  and  brings  the  CODE  concept  fully  to  life  for  the  first  time.  Applications 
can  now  access  some  or  all  of  the  contents  of  a  container.  Multiple  CODEs  can  be  hosted 
on  a  single  platform,  whether  in  support  of  single  or  multiple  DVEs.  Applications  do  not 
directly  access  the  contents  of  the  CODE;  instead,  copies  of  this  information  are  returned, 
allowing  the  application  the  fiexibility  to  modify  that  information  with  no  impact  to  the 


A-9 


Container  ID 
Entity  ID 

Primary  Category 
Secondary  Category 
Tertiary  Category 
Specific  Category 


Data  Segment  (1  KB) 


Figure  A.6  CODE  Container  “Slot” 

CODE.  In  addition,  the  original  CODE  concept  was  extended  to  address  concerns  germane 
to  DVEs.  Persistent  and  non-persistent  containers  control  how  information  is  passed  to 
applications,  while  object  managers  pass  information  between  two  CODEs. 

Perhaps  the  most  significant  ramification  of  this  implementation  is  the  reliance  on 
shared  memory  arenas.  This  concept  is  unique  to  the  IRIX  operating  system;  no  other 
version  of  UNIX  implements  these  arenas.  As  a  result,  this  version  of  the  CODE  performs 
only  on  Silicon  Graphics  platforms.  If  the  CODE  concept  is  to  be  implemented  on  other 
platforms  (e.g.,  Solaris  or  Linux),  another  means  of  allocating  large  amoimts  of  sheired 
memory  will  need  to  be  determined. 

A.  7  Conclusions 

Previous  versions  of  the  CODE  architectiure  were  implemented  through  the  use  of 
several  simplifying  assumptions  that  rendered  them  ineffective  for  the  DMTITE  project. 
Ey  eliminating  these  assumptions,  the  current  implementation  of  the  CODE  provides  a 
robust  architecture  that  can  be  utilized  by  multiple  applications  on  a  single  host,  handles 
user-defined  containers,  and  supports  the  “recmrsive”  implementation  envisioned  by  its 
original  designers.  Since  the  actual  CODEs  are  implemented  as  shared  memory  arenas. 
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and  not  processes,  some  additioneil  overhead  is  introduced  through  the  use  of  “object 
managers”.  These  applications  route  containers  between  CODBs  at  user-defined  intervals. 
Whether  these  “object  managers”  have  a  significant  negative  impact  on  the  DVE  remains 
to  be  determined. 
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Appendix  B.  DMTITE  Design  Methodology 

Figure  B.l  illustrates  the  overall  design  methodology  for  DMTITE  computer  generated 
forces  (CGFs).  A  more  detailed  explanation  follows  in  section  B.2. 


Figure  B.l  DMTITE  Design  Methodology 

The  left  half  of  the  methodology  represents  the  implementation  of  the  cognitive 
model  (the  “Cognitive  Representation  Component”,  or  CRC)  for  a  given  CGF  category. 
This  portion  of  the  methodology  is  performed  only  when  a  CGF  category  has  not  yet 
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been  implemented  or  when  knowledge  needed  by  a  CGF  has  not  yet  been  implemented 
within  a  CGF  category.  The  right  half  of  the  methodology  represents  the  implementation 
of  the  physiceil  model  (the  “Physical  Representation  Component” ,  or  PRC)  for  a  specific 
CGF.  During  this  portion  of  the  methodology,  the  software  engineer  is  concerned  with 
implementing  specific  physical  components  (e.g.,  weapons,  sensors,  and  kinematic  models), 
identifying  the  knowledge  bases  to  be  used  by  the  CGF,  and  specifying  the  CGF’s  entity 
profile  values.  The  first  half  of  the  methodology  is  the  most  time-consuming  (15)  but  is 
performed  less  often  than  the  second  half. 

B.l  Assumptions 

This  design  methodology  assumes  a  taxonomy  has  been  defined  for  the  CGFs  to 
be  supported.  This  taxonomy  must  support  the  concept  that  all  CGFs  within  a  given 
category  share  a  common  cognitive  process,  although  the  knowledge  manipulated  by  this 
process  may  vary  slightly  between  CGFs.  Additionally,  this  methodology  assumes  the 
supporting  software  architecture  has  been  previously  implemented,  verified,  and  validated. 
If  the  imderlying  architecture  has  not  been  verified  and/or  validated,  it  will  be  difficult  (if 
not  impossible)  to  determine  if  processing  errors  are  the  fault  of  the  architecture  or  the 
knowledge  being  input  into  that  architecture. 

B.2  Design  Methodology  Process 

1.  Determine  if  CGF  category  has  been  implemented.  This  step  of  the  methodology  is 
concerned  with  scoping  the  amoimt  of  knowledge  acquisition  to  be  performed  by  the 
knowledge  engineer.  If  the  CGF  category  has  not  yet  been  implemented,  the  knowl¬ 
edge  engineer  must  obtain  all  appropriate  knowledge  from  domain  experts,  manuals, 
and  so  forth.  If,  on  the  other  hand,  the  CGF  category  does  exist,  the  knowledge 
engineer  must  determine  if  2iny  additional  knowledge  is  required  by  the  CGF  being 
implemented.  If  all  necessary  knowledge  has  been  acquired  and  implemented,  no 
knowledge  acquisition  is  necessary  and  the  software  engineer  may  begin  work  at  step 
7. 
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2.  Acquire  knowledge  to  develop  CGF  category.  During  this  step,  the  knowledge  engineer 
elicits  and  documents  knowledge  from  appropriate  sources  using  any  appropriate  and 
available  knowledge  acquisition  technique(s).  The  knowledge  acquisition  performed 
in  this  step  is  limited  to  that  identified  in  step  1;  however,  the  knowledge  engineer 
should  also  identify  any  modifiers  (e.g.,  skills)  for  the  knowledge  in  question.  Al¬ 
though  the  knowledge  engineer  may  choose  to  progress  to  the  next  step  only  after 
knowledge  acquisition  is  complete,  this  step  (along  with  steps  4,  5,  and  6)  will  most 
likely  be  part  of  an  iterative  process. 

3.  Determine  how  skills  impact  the  CGF  category  knowledge.  The  knowledge  engineer 
determines  exactly  how  any  modifiers  identified  in  step  2  affect  the  knowledge  just 
acquired.  For  this,  a  “refinement”  approach  is  recommended:  the  knowledge  engineer 
should  identify  how  an  unmodified  entity  would  view  the  knowledge,  then  determine 
the  impact  of  modification.  Does  the  scope  of  the  knowledge  increase?  Decrease? 
Shift  one  way  or  another?  Or  does  it  exhibit  a  combination  of  these  behaviors? 

Another  approach  that  can  be  used  to  quantify  skills  is  input  modeling.  This  tech¬ 
nique,  used  extensively  in  traditional  simulations,  maps  real-world  data  to  mathe¬ 
matical  distributions  (3).  The  resulting  equations  can  then  be  used  to  map  skills  to 
the  corresponding  value  in  the  distribution. 

If  additional  knowledge  is  required  that  hasn’t  already  been  acquired,  the  knowledge 
engineer  should  return  to  step  2  before  continuing. 

4.  Group  related  knowledge  into  policies.  During  this  step,  the  knowledge  engineer 
first  identifies  knowledge  that  “feeds  off”  other  knowledge  (e.g.,  rules  that  require 
other  rules  to  have  fired  previously),  combining  this  knowledge  into  tightly-  coupled 
knowledge  bases  known  as  policies.  As  this  step  progresses,  the  knowledge  engineer 
should  ensure  no  knowledge  is  duplicated  in  multiple  policies;  if  this  occurs,  the 
affected  policies  should  be  decomposed  into  smaller,  more  atomic  policies. 

5.  Implement  the  decision  engines.  With  the  assistance  of  the  knowledge  engineer,  the 
softweire  engineer  determines  which  inferencing  strategy  will  be  used  for  each  deci¬ 
sion  engine.  The  software  engineer  also  reviews  the  knowledge,  determining  what 
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state  information  each  engine  requires  from  the  physical  state  information  interface 
(PSII).  If  state  messages  haven’t  yet  been  implemented  for  this  information,  the  soft¬ 
ware  engineer  designs  2ind  implements  the  appropriate  data  structures.  If  the  CGF 
category  hasn’t  been  implemented  previously,  the  software  engineer  must  implement 
and  test  each  of  the  decision  engines.  If  the  CGF  category  has  been  implemented  pre¬ 
viously,  the  software  engineer  must  ensure  the  required  state  information  is  properly 
extracted  from  the  PSII. 

If  either  the  knowledge  engineer  or  the  software  engineer  determine  additional  knowl¬ 
edge  not  already  acquire  is  required,  the  knowledge  engineer  should  return  to  step  2 
before  development  continues. 

6.  Encode  the  knowledge  for  each  decision  engine.  The  software  engineer  encodes  each 
policy  into  a  format  readable  by  the  decision  engine(s)  accessing  it.  Each  policy  is 
maintained  in  a  separate  file;  Appendix  C  contmns  the  current  formats  of  policy  files. 

Again,  if  during  this  step  additional  knowledge  is  required,  the  knowledge  engineer 
should  return  to  step  2  before  further  development  occurs. 

7.  Implement  the  “baseline”  initialization  file.  The  “baseline”  initialization  file  contains 
initialization  information  common  to  2J1  CGFs  in  a  given  category  (Appendix  E  con¬ 
tains  the  format  of  these  files.)  Among  other  things,  this  file  specifies  the  inferencing 
strategy  and  knowledge  bases  used  by  each  decision  engine;  the  variables  that  define 
the  category’s  entity  profile;  the  policies  that  comprise  each  knowledge  base;  and  the 
files  that  define  the  policies.  If  the  CGF  category  hasn’t  been  implemented  previ¬ 
ously,  the  software  engineer  must  develop  the  “baseline”  file.  If  the  category  does 
exist,  the  software  engineer  must  ensure  emy  new  state  information,  entity  profile 
variables,  and/or  policies  are  specified  in  the  initialization  file. 

From  this  “baseline”  initialization  file,  the  software  engineer  derives  the  specific  ini¬ 
tialization  file  for  the  CGF  being  developed,  although  at  this  step  the  file  is  incom¬ 
plete.  The  knowledge  engineer  specifies  the  values  (between  0.0  and  1.0  inclusive)  for 
each  of  the  entity  profile  variables  during  this  step,  although  these  may  be  ch2inged 
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as  necessary.  Data  required  by  each  of  the  decision  engines  (e.g.,  weighting  values 
for  case-based  engines)  is  also  specified  at  this  time. 

8.  Identify  the  physical  models  to  be  used  by  the  specific  CGF.  Both  the  knowledge 
engineer  and  software  engineer  identify  the  physical  models  to  be  used  by  the  CGF. 
These  models  provide  the  state  information  for  the  cognitive  representation,  and  are 
directly  or  indirectly  identified  during  the  knowledge  acquisition  phase  (step  2).  This 
step  consists  of  mapping  state  information  to  inputs;  if  no  corresponding  input  exists, 
the  CGF  must  be  able  to  deal  with  this  uncertainty  by  using  the  knowledge  available 
to  it.  The  knowledge  and  software  engineers  also  decide  the  level  of  fidelity  required 
by  the  CGF  during  this  step. 

If  all  identified  physical  models  have  been  implemented  previously,  development  con¬ 
tinues  at  step  10. 

9.  Implement  and  validate  the  physical  models.  Each  of  the  missing  physical  models 
must  be  implemented  by  the  software  engineer.  This  step  consists  of  identifying  the 
functionality  to  be  implemented,  determining  the  state  information  to  be  retrieved 
from  the  sensor  interface,  and  ensiuring  the  corresponding  state  information  is  stored 
in  the  physical  state  information  interface.  The  fidelity  of  the  model  must  correspond 
to  the  level  of  fidelity  identified  in  step  8.  The  software  engineer  also  performs 
sufficient  testing  of  the  operation  of  each  physical  model  developed  during  this  step. 

The  software  engineer  may  also  need  to  add  appropriate  code  to  the  model  initial¬ 
ization  method  of  the  physical  representation  to  allow  each  newly  designed  model  to 
be  instantiated  at  nmtime. 

10.  Add  physical  models  to  the  initialization  file.  Each  physical  model  to  be  used  by 
the  CGF  is  added  to  the  initialization  file  by  the  software  engineer.  Any  arguments 
required  by  eeich  physical  model  (e.g.,  roimds  of  ammunition,  pounds  of  fuel)  are 
also  specified  during  this  step.  The  physical  models  must  be  specified  in  the  order 
they  are  processed  during  nmtime;  models  requiring  inputs  from  other  models  should 
appear  before  the  models  providing  the  inputs. 
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11.  Validate  and  verify  the  implemented  CGF.  Both  the  knowledge  engineer  and  soft¬ 
ware  engineer  validate  and  verify  the  CGF  by  observing  its  behaviors  in  the  virtual 
battlespace.  For  completeness,  the  entity  profile  values  should  be  changed  during 
this  step  to  ensure  the  CGF  displays  an  appropriate  range  of  behaviors.  Newly  de¬ 
veloped  physical  models  and  decision  engines  should  be  examined  closely  to  ensure 
they  fimction  cis  expected.  The  software  engineer  should  use  validated  software  engi¬ 
neering  techniques  to  validate  the  CGF’s  operation;  the  knowledge  engineer  should 
use  accepted  verification  and  validation  techniques  to  evaluate  the  CGF’s  behaviors. 
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Appendix  C.  Policy  File  Formats  and  Examples 

Policies  axe  self-contained  knowledge  bases  that  form  the  “building  blocks”  for  the  knowl¬ 
edge  bases  accessible  by  DMTITE  decision  engines.  Each  policy  and  the  knowledge  base(s) 
that  access  it  is  specified  in  the  initialization  fiie  (see  Appendix  E).  The  actual  knowledge 
contained  in  a  policy  is  specified  in  another  file  called  a  policy  file.  Although  knowledge 
used  by  the  three  inferencing  strategies  supported  by  DMTITE  is  derived  from  a  common 
representation,  eeich  requires  a  speciedized  policy  file.  The  expected  formats  of  these  files, 
as  well  as  a  few  simple  examples,  are  described  in  the  following  sections. 

C.l  General  Expressions 

Each  knowledge  representation  is  comprised  of  one  (or  more)  expressions.  These 
expressions  define  preconditions  (conditions  which  must  be  satisfied  for  a  knowledge  repre¬ 
sentation  to  “fire”),  true  postconditions  (the  set  of  facts  inferred  if  a  knowledge  represen¬ 
tation’s  preconditions  hold),  or  false  postconditions  (the  set  of  facts  inferred  if  a  knowledge 
representation’s  preconditions  are  false).  A  knowledge  representation  cem  have  one,  none, 
or  several  precondition  and/or  postconditions. 

In  general,  expressions  consist  of  two  variables  and  a  relationship  operator  (Figmre 
C.l).  The  variable  on  the  left  hand  side  of  the  expression  never  has  a  veilue  explicitly 
defined  in  an  expression,  while  the  variable  on  the  right  hemd  side  may  have  a  value 
explicitly  defined.  Variable  names  can  be  any  sequence  of  alphammieric  characters  (no 
spaces)  desired,  with  CONSTANT  imderstood  by  DMTITE  to  represent  a  constant  value. 
Variable  types  currently  supported  by  DMTITE  are  shown  in  Table  E.l  (Appendix  E). 
Supported  relational  operators  are  similar  to  those  used  in  the  C/C++  programming 
languages,  as  shown  in  Table  C.l. 

"Left  Hand  Side"  Variable  _  "Right  Hand  Side"  Variable 

Variabie  Name  Variable  Type  Operator  Variable  Name  Variable  Type  Value 

Figure  C.l  General  Expression  Format 
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Table  C.l  Relational  Operators  Supported  by  DMTITE 


Relational  Operator 

Symbol 

equal  to 
not  equal  to 
less  them 

less  than  or  equal  to 

greater  than 

greater  than  or  equal  to 

assignment 

retract 

1  = 

< 

<= 

> 

>= 

retract 

The  format  of  a  retract  expression  is  different  from  other  expressions.  These  expres¬ 
sions  only  have  a  single  variable,  specified  on  the  left  hand  side  of  the  retract  operator. 
When  a  retract  expression  is  executed,  it  removes  the  specified  variable  from  memory. 

Usually,  the  value  specified  for  a  veiriable  must  match  that  variable’s  type.  However, 
DMTITE  currently  supports  three  “value  words”  for  readability,  true  and  false  Me  used 
to  define  the  corresponding  boolean  values,  any.value  can  be  used  by  any  variable  type, 
and  is  used  to  define  “wildcards”.  In  other  words,  a  variable  assigned  any  .value  in  an 
expression  will  always  be  evaluated  as  true,  regardless  of  the  value  that  variable  is  actually 
assigned  in  memory,  any  .value  was  implemented  to  support  case-based  reasoning  (see 
section  C.3).  Finally,  variables  can  be  assigned  formula  values.  These  Me  expressed  in 
postfix  notation  (e.g.,  “2  2  -I-”  to  add  two  and  two  together)  and  may  reference  other 
VMiables.  The  value  of  a  formula  is  calculated  each  time  the  corresponding  expression  is 
evaluated. 

C.2  Rule-Based  Policies 

The  rule-based  inferencing  strategy  used  in  DMTITE  is  based  on  the  standMd  if- 
then-else  format.  The  i/ portion  of  the  rule  represents  the  preconditions,  the  then  portion 
represents  the  true  postconditions,  and  the  else  portion  represents  the  false  postcondi¬ 
tions.  A  rule  in  DMTITE  consists  of  zero,  one,  or  severed  precondition,  false  postcondi¬ 
tion,  and  true  postcondition  expressions  (see  the  previoiis  section).  The  current  rule-based 
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inferencing  engine  in  DMTITE  is  very  basic;  however,  work  continues  on  integrating  a 
public-domain  inferencing  engine  known  as  CLIPS  (C  Language  Implementation  Produc¬ 
tion  System)  into  the  DMTITE  system  design. 

The  rule-based  policy  file  format  is  shown  in  Figure  C.2.  The  <Description>  section 
cont2dns  a  single-line  text  description  of  the  policy.  The  <  Inferencing  Strategy>  section 
contains  a  single  keyword  defining  the  inferencing  strategy  the  policy  supports;  for  rule- 
based  policies,  the  keyword  is  rule-based.  Finally,  the  <Knowledge  Representations> 
section  defines  the  actual  rules.  The  first  line  of  this  section  defines  the  number  of  rules 
comprising  the  policy,  while  the  remaining  lines  describe  the  actual  rules.  Each  rule  is 
defined  by  sever2il  lines.  The  first  contains  the  rule’s  name,  the  number  of  preconditions, 
false  postconditions,  and  true  postconditions.  The  second  line  of  each  rule  contains  a  text 
description  of  the  rule.  This  line  is  followed  by  the  expressions  that  define  the  preconditions, 
then  the  expressions  that  define  the  false  postconditions,  and  finally  the  expressions  that 
define  the  true  postconditions.  This  pattern  is  repeated  for  each  rule  in  the  policy. 

A  portion  of  an  existing  rule-based  policy  is  shown  in  Figure  C.2.  This  particular 
policy  defines  the  computable  combat  psychology  model  (see  Appendix  D);  the  two  rules 
shown  represent  the  conditions  necessary  to  have  a  CGF  hesitate  or  refuse  to  respond 
to  orders  imder  combat  situations.  These  rules  return  booleein  “flags”  to  the  arbitration 
engine,  which  then  acts  upon  them  appropriately.  Both  rules  shown  retract  the  appropriate 
“flags”  from  memory  when  the  preconditions  do  not  hold. 

C.S  Case-Based  Policies 

The  case-based  inferencing  strategy  used  in  DMTITE  associates  a  knowledge  repre¬ 
sentation  to  a  group  of  facts  through  the  use  of  frames.  Frames  were  origin^Jly  developed 
by  Marvin  Minsky,  and  attempt  to  simulate  a  human’s  ability  to  deal  with  new  situations 
by  using  existing  knowledge  of  previous  events,  concepts,  and  situations  (15).  Standard 
case-based  reasoning  selects  a  frame  based  on  some  “goodness-of-fit”  functions,  then  mod¬ 
ifies  that  frame’s  output  to  match  differences  between  the  selected  frame  and  the  cmxent 
situation.  The  cinrent  case-based  inferencing  engine  used  in  DMTITE  does  not  modify 
the  output  of  the  frame  it  selects. 


C-3 


<Description> 
text -description 


<Inferencing  Strategy> 
rale-based 

<Knovledge  Representation8> 

#-of-knovledge-representations 

representation-name  t-of-preconditions  #.of-false-postconditions  *-of-trae-postconditions 

representation-description 

precondition-ezpression-l 

precondition-expression-T 

fedse.postcondition-expression-l 

false-postcondition-expression-s 
tme-po  St  condit  ion-expression-1 

tme-postcondition-expression.t 

representation-name  i-of-preconditions  i-of-false-postconditions  i-of.tme-postconditions 

representation.description 

precondition.1 

precondition-x 

false-postcondition-expression-l 

lalse-postcondition-expression-y 

trae-postcondition.expression-l 

tme-postcondition-expression-Z 


Figure  C.2  Rule-Based  Policy  File  Format 


Case-based  policies  are  similar  to  rule-based  policies,  with  one  exception:  each  knowl¬ 
edge  unit  has  the  same  number  of  pre-  and  postconditions.  The  expected  format  for  a 
case-based  policy  file  is  identical  to  that  for  a  rule-based  policy  (see  Figure  C.2),  except 
that  the  <Inferencing  Strategy>  section  specifies  case-based  as  opposed  to  rule-based.  A 
portion  of  a  case-based  policy  is  shown  in  Figure  C.3.  This  particular  policy  is  used  by  an 
einti-2iircraft  artillery  (AAA)  CGF  while  in  search  mode;  the  frame  shown  transitions  the 
AAA  CGF  from  search  mode  to  target  acquisition.  If  additional  knowledge  representations 
were  added  to  this  file,  they  would  be  required  to  have  twelve  preconditions  (referencing 
the  variables  shown  in  the  example),  no  false  postconditions,  and  one  true  postcondition. 
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<Description> 

Defines  the  computable  combat  psychology  model. 

<Inferencing  Strategy> 
rule-based 

<Knowledge  Representations> 

2 

Delayed-Response  211 

CGF  is  anxious  but  not  aggressive,  so  delay  response  1  to  4  seconds. 

anxiety  double  >  CONSTANT  double  0.70 

anger  double  <  CONSTANT  double  0.50 

delay-response  retract 

delay-response  bool  =  CONSTANT  bool  true 

Refuse-To-Respond  2  12 

CGF  is  anxious  and  not  receptive  to  orders,  so  refuse  to  respond  to  orders. 

anxiety  double  >  CONSTANT  double  0.85 

acquiescence  double  <  CONSTANT  double  0.80 

refuse-to-respond  retract 

delay-response  retract 

refuse-to.respond  bool  *=  CONSTANT  bool  true 


Figure  C.3  Portion  of  Sample  Rule-Based  Policy 
C.4  Fuzzy  Logic  Policies 

Fuzzy  logic  requires  extensions  to  the  general  expressions  not  required  by  either 
case-based  or  rtile-based  reasoning.  Some  of  the  variables  take  the  form  of  fuzzy  sets 
which  encode  imprecision  by  mapping  a  range  of  vedues  to  a  membership  function.  A 
membership  fimction  is  usually  nothing  more  them  a  mathematical  function;  DMTITE 
currently  supports  increasing  linear,  decreasing  linear,  increasing  S-curve,  decreasing  S- 
curve,  pi  curve,  weighted  beta  curve,  gaussian  curve,  proportional,  arbitrary,  and  singleton 
membership  functions.  A  value’s  membership  in  a  fuzzy  set  can  be  modified  through  the 
use  of  hedges.  Hedges  are  domain-independent  mathematical  fimctions  that  approximate 
the  linguistic  characteristics  of  the  hedge;  the  hedges  currently  supported  by  DMTITE, 
ailong  with  their  meaning,  are  shown  in  Table  C.2.  When  combined,  these  concepts  support 
rules  such  as  “if  temperature  is  somewhat  hot  then  motor  speed  is  usually  moderate.”  This 
rule  can  be  invoked  using  imprecise  (“fuzzy”)  values  for  “motor  speed”  and  “temperature”; 
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<Description> 

Defines  the  cases  of  detecting  enemy  aircraft  using  eyes  or  radar/IFF. 

<Inferencing  Strategy> 

case-based 

<Knowledge  Repres6ntations> 

1 

Target_In_Range_To_Acquire  12  0  1 

Target  detected  and  in  range,  ready  to  acquire. 

current -State  int 

==  CONSTANT  int  0 

search-mode  int 

==  CONSTANT  int  any_value 

firejnode  int 

==  CONSTANT  int  any_value 

target-visible  bool 

==  CONSTANT  bool  false 

visual-confidence  double 

>=  visual.threshold  double 

accousticjdetection  bool 

==  CONSTANT  bool  any_value 

remote-detection  bool 

==  CONSTANT  bool  any _ value 

in-radar-LOS  bool 

==  CONSTANT  bool  any_value 

in-optical-LOS  bool 

==  CONSTANT  bool  any_value 

in-engagement -range  bool 

==  CONSTANT  bool  any _ value 

target -inbound  bool 

==  CONSTANT  bool  true 

time-not-visible  double 

«=  CONSTANT  double  any .value 

next-state  int 

==  CONSTANT  int  2 

Figure  C.4  Portion  of  Sample  Case-Based  Policy 


an  exact  motor  speed  can  be  obtained  by  “defuzzifying”  the  result  of  the  rule.  Specific 
information  on  fuzzy  sets,  membership  functions,  hedges,  and  defuzzification  can  be  found 
in  Cox  (10). 

The  fuzzy  logic  policy  file  format  is  shown  in  Figure  C.4.  This  format  is  similar  to 
that  used  by  rule-based  and  case-based  policies;  however,  it  adds  a  <Fuzzy  Sets>  section 
to  define  the  fuzzy  sets  to  be  used  within  a  policy.  Fuzzy  sets  are  defined  by  their  type,  an 
“alpha  cut”  (a  minimum  membership  value — ^values  below  this  are  treated  as  zero),  and  a 
list  of  fuzzy  set  parameters.  Each  type  of  fuzzy  set  requires  a  different  set  of  parameters; 
these  parameters  are  defined  in  Cox  (10)  and  not  repeated  here. 

Changes  also  appear  in  the  <Knowledge  Representations>  section  of  a  fuzzy  logic 
policy.  Since  fuzzy  sets  don’t  correspond  to  other  data  types,  no  variable  type  or  value  is 
given  for  fuzzy  sets  used  in  an  expression.  This  does  not  exclude  treuiitional  variables  from 
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Table  C.2  Fuzzy  Set  Hedges  Supported  by  DMTITE  (10) 


Hedge 

Meaning 

usually 

contrast  diffusion 

above,  more  than 
almost,  definitely, 

restrict  a  fuzzy  region 

positively 

contrast  intensification 

below,  less  than 

restrict  a  fuzzy  region 

generally,  usually 

contrast  diffusion 

not 

negation  or  complement 

quite,  rather,  somewhat 

dilute  a  fuzzy  region 

very,  extremely 
about,  around,  near. 

intensify  a  fuzzy  region 

roughly 

approximate  a  scalar 

vicinity  of 

approximate  broadly 

neighboring,  close  to 

approximate  narrowly 

being  combined  with  fuzzy  sets;  if  so,  variables  must  state  their  type  and  (if  appropriate) 
their  value. 

A  pricing  policy  example  from  Cox  (10)  was  used  to  verify  the  operation  of  the  fuzzy 
logic  inferencing  engine  developed  for  use  in  DMTITE;  this  policy  is  shown  in  Figure  C.4. 
While  not  related  to  the  DMTITE  domain,  this  example  shows  how  facts  can  be  stated 
using  general  expressions  (no  preconditions  given)  and  demonstrates  the  general  format  of 
a  fuzzy  logic  policy. 
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<De8cription> 
text -description 

<Inferencing  Strategy> 
fuzzy-logic 

<Fiizzy  Sets> 

#-of-fnzzy-8ets 
fnzzy-set-name 
fnzzy-set-type  alpheucnt 
f  nzzy-s  et -paramet  er  8 
liedges-to-apply 

<Knosledge  Repre8entation8> 

#-of-knovledge-repre8entation8 

representation-name  t-of-preconditiona  t-of-false-postconditions  #-of.tme-po8tconditions 

representation-description 

precondition-ezpression-l 

precondit ion-expres  sionjr 
fells  e.po  St  condit  ion-expres  sion-l 

false-postcondition-expression-s 
trne-post condition-expression-1 

tme-po  St  condit  ion-expres  s  ion-t 

representation-name  #-of-precondition8  t-of-false-postconditions  t-of-tme-postconditions 

representation-description 

precondition-1 

precondition-X 

false-post condition-expression-1 

false-postcondition-expression-y 

tme-postcondition-expression-l 

tme-po  St  condition-express  ion-z 

Figure  C.5  Fuzzy  Logic  Policy  File  Format 
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<Description> 

Defines  the  example  price  strategy  policy. 

<Inferencing  Strategy> 
fuzzy-logic 

<Fuzzy  Sets> 

5 

HIGH 

INCREASING-LINEAR  0 
16.0  36.0  16.0  36.0 
LOW 

DECREASINGXINEAR  0 

16.0  36.0  16.0  36.0 

Around-Twice-Manufacturing-Costs 

PI-CURVE  0 

16.0  36.0  24.0  6.0 

NVHigh 

INCREASINGXINEAR  2 
16.0  36.0  16.0  36.0 
VERY  NOT 

Around-Competition-Price 

PI-CURVE  0 

16.0  36.0  28.0  4.0 

<Knowledge  Representations> 

2 

First-Knowledge  003 

Builds  the  base  price  fuzzy  output  set. 

Price  =  HIGH 

Price  =  LOW 

Price  =  Around_Twice_Hanufacturing_Costs 

Second-Knowledge  101 

Builds  the  variable  part  of  the  price  output  set. 

Competition-Price  ==  NVHigh 

Price  =  Around_Competition_Price 

Figure  C.6  Portion  of  Sample  Fuzzy  Logic  Policy 
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Appendix  D.  Computable  Combat  Psychology  Model 

The  following  model  was  based  on  a  study  of  the  behavioral  effects  of  combat  stress  by 
Dr.  Steven  Silver,  currently  an  associate  clinical  professor,  Department  of  Psychiatry, 
Temple  University  Medical  School.  It  was  originally  intended  for  use  in  Atomic  Games’ 
Close  Combat,  a  computer  game  simulation  of  the  Normandy  campaign  of  World  Wax  11. 
According  to  Dr.  Silver,  Atomic  Games  elected  to  incoporate  only  the  basic  concept  of 
the  model  in  their  final  product,  citing  the  limited  computational  power  of  the  personal 
computers  being  targeted  for  the  game  (30). 

This  model  was  developed  using  literature  analyzing  human  reactions  in  combat  (16, 
23)  and  the  “trait-state”  field  of  psychology.  The  basic  concept  is  that  each  individual 
has  an  unique  psychological  profile,  resulting  in  probabilistic  responses  in  various  stressful 
situations.  The  goal  of  the  model  is  to  be  able  to  simulate  a  wide  range  of  combat  behaviors, 
from  the  rage  reaction  of  a  friend’s  death  to  a  soldier  who  would  not  only  disobey  but  kill 
his  commander  (31).  When  approached  about  incorporating  his  impublished  model  into 
DMTITE,  Dr.  Silver  readily  agreed,  providing  the  model  description  that  follows  (29). 

The  following  sections  describe  trait-state  psychology,  the  model  as  it  was  originally 
proposed,  and  how  the  model  was  actually  implemented  in  the  DMTITE  project. 

D.l  “Trait’State”  Psychology 

Trait-state  psychology  views  human  functioning  in  terms  of  fundamental  traits;  all 
people  have  all  traits  in  varying  degrees,  depending  upon  genetics  and  life  experience. 
This  particular  approach  to  psychology  was  selected  because  it  can  be  translated  into  a 
numerical  format,  easing  the  programming  task. 

In  trait-state  psychology,  a  trait  is  relatively  stable  and  doesn’t  fiuctuate  much;  it 
represents  the  “normal”  value  for  a  particiilar  individual.  States,  on  the  other  hand,  are 
derived  firom  trriits  and  are  situational;  they  represent  an  individual’s  transitory  response 
to  a  situation.  For  example,  consider  anxiety  as  a  trait  and  as  a  state.  A  “normal”  person 
may  have  an  anxiety  trait  of  10  (on  a  0-100  sceile).  When  surprised  by  a  balloon  popping, 
a  person  may  experience  an  anxiety  state  of  20.  Treiits  and  states  are  combined  in  a 


D-1 


situation,  then  behaviors  are  induced  based  on  real  world  observations.  Returning  to  the 
einxiety  example,  assume  that  ein  anxiety  level  (trait  +  state)  of  more  than  70  has  been 
observed  to  affect  behavioral  functioning.  An  anxious  individueJ  (with  2in  anxiety  trait 
of  60)  would  display  these  effects  when  surprised  by  a  balloon  popping  (since  60  +  20  is 
more  th2in  the  threshold  value  of  70).  A  probabilistic  or  other  appropriate  approach  can 
be  taken  to  induce  the  appropriate  effects  based  on  the  situation. 

In  short,  then,  the  trait-state  approach  to  psychology  evaluates  a  given  situation  by 
determining  the  current  state,  applying  it  to  the  existing  trait,  and  displaying  the  resulting 
reactions  and  behavior  of  the  individual. 

D.2  Limitations  and  Assumptions 

While  the  trait-state  approach  allows  a  straightforward  approach  to  modeling  psy¬ 
chology,  the  model  is  inherently  incomplete.  As  a  whole,  human  functioning  is  not  com¬ 
putable  and  while  group  behavior  is  generally  predictable  given  certain  conditions,  indi¬ 
vidual  behavior  is  far  less  so.  This  model  assumes  the  best  predictor  of  individual  human 
behavior  is  that  individual’s  past  behavior.  As  a  result,  this  model  is  essentially  stable;  that 
is,  wide  variations  in  ein  individued’s  behavior  should  be  uncommon,  but  not  impossible. 
Furthermore,  group  behavior  is  assumed  to  be  a  compilation  of  individual  behavior.  The 
results  of  both  individual  and  group  behavior  are  assumed  to  be  reflected  in  performance, 
aind  the  results  of  that  performance  should  feedback  into  individual  and  group  states  and 
traits. 

This  model  is  limited  to  functions  relating  to  combat,  including  leadership,  command, 
communication,  control,  morale,  and  military  skills  performance.  Within  these  functions, 
this  model  allows  form  inhibitions  and  enhancements  of  performance,  such  as  speed  of 
movement,  accuracy,  and  cooperation.  The  model  also  provides  for,  to  a  limited  extent, 
unusual  individual  behavior,  including  running  amok,  charging  the  enemy,  hesistation,  and 
peinic-stricken  rout.  Since  the  full  reinge  of  potential  hiunan  behavior  cannot  be  modeled, 
only  those  behaviors  most  relevant  to  performance  for  will  be  accoimted  for.  This  model 
was  developed  utilizing  the  behavior  of  20th  century  infantry;  despite  this,  it  is  assumed  to 
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be  applicable  to  all  forms  of  individual  and  team  combat.  This  assumption  seems  justifiable 
because  human  psychology  has  remained  relatively  constant  since  it  was  first  documented. 

D.3  Definitions 

There  are  three  types  of  variables  used  in  this  combat  psychology  model.  As  stated 
previously,  traits  rem^dn  relatively  constant;  however,  they  serve  as  the  initi2il  correspond¬ 
ing  state  value,  which  are  dynamic  in  nature.  In  addition,  a  series  of  computed  variables 
can  be  derived  from  both  treats  and  states.  These  variables  are  defined  in  the  following 
sections. 

D.  3. 1  Traits  and  States.  The  following  explicit  traits  and  states  are  used  to  model 
human  behavior  in  combat  situations.  Each  is  assumed  to  be  present  to  some  degree  in 
each  individual. 

1.  Stability.  A  generic  term  encompassing  emotional  stability  functions  as  opposed  to 
particular  emotions.  It  serves  as  the  “governor”  of  emotional  expression,  particularly 
extreme  emotional  expression  such  as  panic. 

2.  Anxiety.  Inherent  fearfulness. 

3.  Anger.  A  generic  term  encompassing  the  emotion  of  anger,  this  variable  also  accounts 
for  aggressiveness. 

4.  Humor.  More  than  a  simple  sense  of  humor,  this  variable  eilso  eiccounts  for  emotional 
“boimce-back”  eind  the  ability  to  recover  from  sudden  shocks,  losses,  and  other  neg¬ 
ative  impactors  on  morale. 

5.  Acquiescence.  The  willingness  to  follow  commands,  orders,  and  other  leaders. 

6.  Independence.  The  ability  to  fimction  independently,  without  leadership. 

7.  Charisma.  A  variable  refiecting  aspects  of  personality  that  others  find  attretctive. 

8.  Knowledge.  This  term  was  selected  to  replace  “Intelligence”,  which  has  a  particular 
meaning  in  military  terms.  It  refers  to  military  knowledge,  ranging  from  weapons 
and  equipment  to  tactics. 
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D,S.2  Computed  Variables.  The  following  variables  are  computed  from  the  traits 
and  states  defined  in  section  D.3.1.  Note  that  Support,  Leadership,  and  Morale  are  calcu¬ 
lated  states,  not  just  variables. 

1.  Situational  Stress.  Calculated  as  the  ratio  of  friendly  to  enemy  combatants  in  the 
engagement,  with  addition/subtraction  provided  by  fi'iendly /enemy  supporting  fire 
and  Fatigue. 

2.  Support.  Refiects  an  individual’s  ability  to  psychologically  support  other  members  of 
the  team.  It  is  calculated  from  the  individual’s  Stability,  Humor,  and  Acquiescence 
veJues. 

3.  Group  Support.  Calculated  as  the  group  average  of  each  individual’s  Support  value. 

4.  Leadership.  The  ability  of  an  individual  to  command  the  obedience  of  others.  It 
is  Ccilculated  fi:om  the  individuril’s  Independence,  Charisma,  Anger,  and  Knowledge 
values. 

5.  Morale.  Calculated  from  an  individual’s  Stability,  Anxiety,  Anger,  and  Humor  values; 
the  related  Group  Support  and  Situational  Stress  values;  and  the  group  leader’s 
Leadership  value. 

D.4  Model  Functionality 

This  section  describes  the  model  functionality  prior  to,  at  the  start  of,  and  at  the 
conclusion  of  a  given  simulation.  PunctionaJity  during  a  simulation  is  described  in  sections 
D.5,  D.6,  and  D.7. 

D.4.1  Initial  Phase.  The  explicit  treiits  defined  in  section  D.3.1  are  determined 
prior  to  the  start  of  a  given  simulation.  These  values  can  be  specified  or  generated  ran¬ 
domly;  if  generated  randomly,  the  values  should  be  between  0.2  and  0.8  (on  a  O.O-l.O  scale), 
normally  distributed  as  shown  in  Table  D.l. 

These  values  are  calculated  once  for  each  individual;  once  calculated,  they  represent 
the  “baseline”  values  (traits)  for  that  individual. 
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Table  D.l  Initial  Trait  Value  Probabilities 


Value 

Distribution 

13% 

20% 

34% 

20% 

13% 

D.4-S  Initial  Phase  Computations.  Once  the  initial  traits  have  been  determined, 
the  calculated  variables  and  states  are  generated  as  follows: 


^  ^  Stability  +  Anxiety  + 

3.5 

Note  that  the  Situation  Stress,  Group  Support,  and  group  leader’s  Leadership  values 
are  not  included  in  this  initial  computation. 


„  Stability  +  Humor  +  Acquiescence 

Support  =  - g - 

,  ,  ,  .  Independence  +  Charisma  +  Knowledge  +  Stability  +  Morale 

Leadership  =  - - - 

5 

These  values  are  calculated  once  for  each  individual;  once  calculated,  they  represent 
the  “baseline”  values  (traits)  for  that  individual. 

D.4.3  Operational  Phase  Adjustments.  At  the  start  of  each  simulation  in  which 
an  individual  participates,  the  state  Morale  value  is  calculated  as  follows: 


state  Morale 


trait  Morale  +  Leadershi^+  Group  Support 


(D.2) 


D-5 


In  addition,  each  of  the  individual’s  “baseline”  traits  become  the  individueJ’s  initial 
states  for  the  simulation. 

D.4‘4  Trait  Adjustments.  At  the  end  of  each  simulation  in  which  an  individual 
participates,  the  initial  trait  values  are  modified  as  follows: 


(initial  trait  —  ending  state)  >  0.20  =>  initial  trait  =  initial  trait  +  0.05 
(initial  trait  —  ending  state)  <  —0.20  ^  initial  trait  =  initial  trait  —  0.05 

D.5  State  Changes 

An  individual’s  states  will  change  in  response  to  the  situational  stress  of  the  envi¬ 
ronment  and  the  group.  In  turn,  the  changes  in  the  individual  will  induce  changes  in  the 
group.  To  avoid  perpetueil  loops,  the  sequence  of  evaluation  should  be  environment,  then 
the  group.  The  following  is  an  example  of  environmental  variables  and  their  impact  (as 
approximated  from  various  studies  done  on  the  psychology  of  the  battlefield). 

D.5.1  Battlefield  Variables.  The  battlefield  variables  affecting  individual  states 
are  shown  in  Table  D.2;  those  edfecting  group  states  are  shown  in  Table  D.3.  These  values 
are  fairly  rigid;  if  preferred,  a  situational  stress  computation  could  be  used  for  proportional 
point  allocation. 

D.5. 2  Stress  Reduction  Variables.  The  stress  reduction  variables  specify  events 
that  reduce  or  improve  states  both  immediately  (Table  D.4)  and  over  time  (Table  D.5). 

D.6  Effects  of  States  on  Performance 

Once  the  current  state  of  a  CGF  has  been  evaluated,  the  effects  of  that  state  need  to 
be  refiected  in  its  behaviors.  There  are  many  different  ways  to  modify  a  CGF’s  behavior 
based  on  its  state,  as  discussed  in  the  following  sections. 
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Table  D.2  Battlefield  Variables  (Individual  Elements) 


Event 

Stab. 

Anx. 

Ang. 

Hum. 

Acq. 

Ind. 

Char. 

Know. 

New  team  member 

-0.05 

M 

-0.05 

■1 

Nighttime  conditions 

iii 

nny 

0.02 

-0.01 

Reduced  visibility 
Indirect  fire 

0.05 

-0.01 

0.01 

(intermittent) 

Indirect  fire 

0.01 

0.01 

(continuous)® 

0.03 

0.02 

-0.01 

-0.01 

Sniper  fire 

Light  (ineffective) 

0.02 

0.01 

-0.01 

0.01 

fire 

0.05 

-0.01 

-0.01 

niiM 

Moderate  fire 

-0.03 

0.08 

-0.02 

-0.02 

-0.01 

0.01 

Heavy  fire 

-0.05 

0.12 

-0.04 

-0.05 

-0.01 

-0.01 

0.01 

Ambushed 

-0.03 

0.10‘ 

-0.02 

-0.04 

-0.03 

0.01 

Minefield 

-0.02 

0.05 

0.01 

Knma 

-0.03 

-0.02 

0.01 

Attacked  by  inferior 
force 

0.05 

0.08 

0.01 

0.01 

0.01 

Attacked  by  force  of 
equal  size 

Attacked  by  superior 

0.06 

0,02 

-0.01 

0.01 

force 

-0.01 

0.06 

-0.01 

-0.02 

-0.01 

-0.01 

0.01 

Attacked  by 
overwhelming  force 
Ambushing  an  inferior 

0.10® 

-0.01 

-0.10 

-0.04 

-0.02 

-0.02 

0.01 

force 

0.02 

0.10 

0.02 

0.02 

0.01 

0,01 

Ambushing  force  of 
equal  size 

Ambushing  a  superior 

0.03 

0.10 

0.01 

0.01 

force 

0.04 

0.10 

-0.01 

-0.01 

0.01 

Supporting  fire  on  call 

0.10 

0.02 

0.05 

0.04 

0.02 

Close  quarters  combat 
Encoimtering  dead 

0.01 

-0.02 

0.01 

0.01 

0.01 

0.01 

enemy 

Encountering  wounded 

-0.01 

0.02 

0.01 

0.01 

0.01 

0.01 

enemy 

-0.01 

0.01 

0.03 

0.01 

“Every  15  minutes 
*’Every  15  minutes 
“Every  30  minutes 


D-7 


Table  D.3  Battlefield  Variables  (Group  Elements) 


Event 

Stab. 

Anx. 

Ang. 

Hum. 

Acq. 

Ind. 

Char. 

Know. 

Teeim  member  wounded 
(TCR“  <  10%) 

Tetim  member  wounded 

-0.02 

0.02 

0.02 

-0.01 

(10%  <  TOR  <  40%) 
Team  member  woimded 

-0.03 

0.04 

0.04 

-0.02 

-0.01 

-0.01 

(TOR  >  40%) 

Team  member  killed 

-0.04 

0.05 

0.04 

-0.05 

-0.02 

-0.02 

(TCR  <  10%) 

Team  member  killed 

-0.04 

0.04 

0.04 

-0.02 

-0.01 

(10%  <  TCR  <  40%) 
Team  member  killed 

-0.05 

0.05 

0.05 

-0.05 

-0.02 

-0.02 

(TCR  >  40%) 

-0.06 

0.07 

0.05 

Hjxna 

-0.03 

-0.03 

Team  leader  wounded 

-0.04 

0.05 

0.03 

-0.03 

Team  leader  killed 
Incorrect  orders 

-0.08 

0.10 

0.03 

■ 

-0.05 

0.02 

given 

-0.03 

0.05 

0.05 

-0.02 

-0.09 

0.01 

“Team  Casualty  Rate-,  percentage  of  team  wounded  or  killed 


D,6,l  Tasks  Relating  to  Reaction  Time.  Tasks  relating  to  reaction  time,  such 
as  taking  cover,  are  affected  as  follows.  Delay  is  a  randomized  variable  between  0  and  4 
seconds. 


{Anxiety  >  0.70)  A  {Anger  <  0.50)  =>•  Delay 
{Anxiety  >  0.85)  A  {Acquiescence  <  0.80)  =!►  Delay  +  10  seconds 

D.6.2  Accuracy  and  Weapons  Handling  Effectiveness.  In  general,  effectiveness 
is  reduced  when  Knowledge  is  less  than  0.50  and  is  enhanced  when  Knowledge  is  greater 
than  0.80  (29).  To  model  the  effects  of  fear  on  accuracy,  rate  of  fire,  and  other  related 
tasks  (23),  use  Morale  as  follows. 
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Table  D.4  Stress  Reduction  Variables  (Immediate  Effects) 


Event 

Stab. 

Ana.® 

Ang. 

Hum. 

Acq. 

Ind. 

Char. 

Know. 

Issued  more  effective 
equipment 

Issued  new  clothing 

-0.05 

Successful  defense 

-0.05 

0.01 

■itiW 

0.01 

Successful  attack 

-0.02 

-0.06 

0.04 

0.05 

llllfl 

0.01 

Eating  a  meal 

0.01 

-0.10 

-0.01 

0.02 

0.01 

0.01 

“If  value  >  0.70,  effects  Me  doubled 


Table  D.5  Stress  Reduction  Variables  (“Timed”  Effects) 


Event 

Stab. 

Anx.^ 

Ang. 

Hum. 

Acq. 

Ind. 

Char. 

Know. 

Sleep^ 

-0.02 

0.01 

HOI 

No  fire,  secure  position® 
No  fire*^ 

HI 

-0.02 

0.01 

-0.02 

-0.01 

0.01 

“If  value  >  0.70,  effects  Me  doubled 
‘Every  30  minutes 
'Every  30  minutes 
‘‘Every  30  minutes 


Morale  >  0.80  ^ 
Morale  <  0.50  =► 


increased  effectiveness 
reduced  effectiveness 


To  accoimt  for  the  dominant  nature  of  fe2ir  on  the  battlefield,  an  additional  degra¬ 
dation  in  effectiveness  occurs  when  Anxiety  is  greater  than  0.80. 

D.6.3  Obedience  to  Orders.  This  effect  refiects  whether  or  not  an  individual  will 
obey  orders,  not  how  quickly  those  orders  will  be  carried  out.  Under  “normal”  conditions, 
the  orders  will  be  acted  upon  immediately;  however,  the  individual  can  also  Hesistate  (fail 
to  carry  out  the  orders  until  they  are  repeated)  or  Disobey  (fail  to  carry  out  the  orders 
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regardless  of  how  many  times  they  axe  repeated).  The  latter  two  conditions  are  defined  as 
follows: 


{Morale  <  0.40)  A  {Anxiety  >  0.70)  A  {Acquiescence  <  0.40)  Hesistate 

{Morale  <  0.40)  A  {Anxiety  >  0.80)  A  {Acquiescence  <  0.35)  A 
{Support  <  0.50)  A  (leader’s  Leadership  <  0.50)  A  {Random  >  0.50)  =>  Disobey 

{Random  is  a  randomized  value  between  0.0  and  1.0  inclusive.)  There  are  also  ex¬ 
tremely  rare  circumstances  where  an  individual  will  not  only  disobey  an  order  but  also 
strike  out  at  the  issuing  authority.  In  the  Vietnam  conflict,  this  was  known  as  “fragging” 
and  can  be  defined  as  follows: 


{Morale  <  0.40)  A  {Anxiety  >  0.80)  A  {Acquiescence  <  0.30)  A 

{Support  <  0.40)  A  (leader’s  Leadership  <  0.50)  A  {Random  >  0.70)  =>■  Frag 

D.7  Unusual  Behaviors  Induced  by  States 

A  CGF’s  state  not  only  affects  its  behaviors,  but  may  also  induce  “unusual”  behaviors 
for  given  situations.  These  behaviors,  eind  the  states  that  induce  them,  are  discussed  in 
the  following  sections. 

D.7.1  Panic  Reactions.  Most  studies  emphasize  the  role  of  isolation  when  an 
individual  flees  the  battlefield  by  breaking  and  running.  Conversely,  the  greatest  pre¬ 
ventative  appears  to  be  peer  support  followed  closely  by  the  individual’s  perception  of 
team  leadership.  K  one  individual  breaks,  the  probability  of  other  team  members  breaking 
increases  as  well. 
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{Morale  <  0.50)  A  [Anxiety  >  0.80)  A  [Stability  <  0.50)  A 
[Support  <  0.40)  A  (leader’s  Leadership  <  0.40)  A  [Random  >  0.50)  =►  Flee 

D.7.2  Heroism.  This  type  of  behavior  has  not  been  very  well  studied  (16),  as 
most  armed  forces  are  not  so  much  concerned  with  understanding  the  behavior  of  those 
rare  people  called  “heroes”  as  they  have  been  in  trying  to  prevent  the  far  more  conunon 
behavior  of  individuals  overcome  by  anxiety.  Despite  this,  Heroism  can  be  simulated  when 
the  following  combinations  of  states  exists: 


[Support  >  0.85)  A  [Morale  >  0.60)  A  [Anger  >  0.70)  A 

[Independence  >  0.75)  A  [Random  >  0.50)  =►  Heroism 

D.7.3  Atrocities.  Atrocities  are  displayed  in  two  ways:  killing  unarmed  civilians 
and  killing  disarmed  and  taken  prisoners-of-war.  As  with  heroism,  this  behavior  has  not 
been  well  studied  (16).  However,  this  behavior  can  occur  when  the  following  conditions 
hold: 


[Morale  <  0.50)  A  [Anger  >  0.80)  A  (leader’s  Leadership  <  0.50)  A 

[Random  >  0.70)  Atrocity 


D.8  Incorporating  the  Model  into  DMTITE 

The  traits  and  states  aspects  of  this  model  have  been  combined  with  the  “skills 
vector”  identified  by  Santos,  et  al.,  for  their  general  CGF  architecture  (27).  The  initial 
values  are  explicitly  defined  by  the  user  in  the  CGF  initialization  file;  they  are  not  randomly 
generated.  The  entire  model  is  mmntmned  by  the  Arbitration  Engine;  this  engine  is 
responsible  for  updating  the  states  of  the  entity  and  ultimately  displaying  the  behaviors 
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corresponding  to  the  current  state  of  the  CGF.  The  current  implementation  of  the  model 
is  expressed  as  a  set  of  rules;  therefore,  the  Arbitration  Engine  uses  rule-based  inferencing 
to  determine  the  state  of  a  given  CGF. 

The  group  aspects  of  this  model  have  yet  to  be  incorporated  into  DMTITE.  While 
the  software  architecture  is  designed  to  allow  the  inclusion  of  cooperation  and  coordination 
between  CGFs,  the  actucd  means  to  do  so  have  yet  to  be  determined.  As  a  result,  CGFs 
have  no  means  of  “sharing”  information  (such  as  their  traits  and  states,  or  their  behaviors). 
Unfortimately,  the  group  aspect  is  a  large  portion  of  Dr.  Silver’s  model  and  many  of  the 
behaviors  supported  by  the  model  cannot  be  currently  displayed  by  DMTITE  CGFs. 
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Appendix  E.  Initialization  File  Format  and  Example 

A  DMTITE  CGF  is  defined,  in  part,  by  the  file  used  to  initialize  it.  This  appendix  defines 
the  expected  format  of  the  CGF  initialization  file.  Each  entry  in  the  initialization  file  is 
presented  and  defined  values  for  specific  entries  are  also  identified.  A  partial  example  of  a 
working  initialization  file  concludes  this  appendix. 


E.l  Initialization  File  Format 

The  expected  format  for  a  DMTITE  initialization  is  shown  in  Figure  E.l.  The 
initialization  file  is  divided  into  several  sections,  each  of  which  is  described  below. 


<Eiitity  lnfozmation> 

<KBOsladga  Basas> 

calls  iga 

• 

aatioaality 

kao*ladga.basajiaaM  iBfaraBciag.stratagy  B^f^Mlleias 

4oMdn 

kBosladga..basajdascripti6B 

category 

pollcyjtasiaCs) 

•pacific 

<LoBg*Tani  BBgiBa> 

<Initial  CoBflgaratloB> 

lafaraBClag^tratagy  Juovladga.basas  ltaovladga.baaajMSia(s) 

VQS^.dCoordlBatas  0.0  0.0  0.0 

(iBfaraaclag-^dapaBdaat  lafarMtloa) 

aalar.juiglas  0.0  0.0  0.0 

liBaar.valecity  0.0  0.0  0.0 

<lllssloB-LaTal  EBgiBa> 

llBaar^calaratloB  0.0  0.0  0.0 

iafaraBciag^tratagy  Juo«ladgaJ»asas  kBovladga.basa4Maia(s> 

(lafaraaciBg~dapaadant  iaferaatioB) 

<BBviroa»aBt  laforBatioB> 

axarcisaJD 

<Crltleal  SBglBa> 

aatltyJlD 

iafaraaelag.stratagy  t.Af^otladga.^as  kBovladgaJ>asajBsaia(s> 

laad^atltyJD 

(iafaraBciBg^dapaBdaBt  iafonsatioa) 

coBnact.toJCQDB  Bsaa.of.CODB 

doaalas^fUatarast  •  (land  sarfaea  air  spaca) 

<ArbitratloB  EaglBa> 

iafarcBclBg^tratagy  jLBOvladga.basas  kBovladgaJ»asajiaBa(s) 

<EBtity  Proflla> 

(lafaraaclBg^dapaBdaBt  laforvatioa) 

stability  0.0 

<wn> 

aaziaty  0.0 

Bassaga.strnctara.fllaaaMa 

angar  0.0 

qBary.stractvra^llaBasia 

haaar  0.0 

acqBlascaBca  0.0 

<niysical  CoapOBaBts> 

iBdapaadaaca  0.0 

• 

charissa  0.0 

eaapoBaatJdaatlflar  coapoBaBt.argwaBt(s) 

knosladga  0.0 

skllljiaaa  0.0 

<SaBser  lBtarfaca> 

aassaga^tractora^fllaBBaa 

<Pollclas> 

qBaryjtrDctiira.filaBa»a 

policyjiaaa  pollcyjrilaaaaa 

<Zaltlal  Paraaatars> 

paraaatarjiMM  paraaatarJtypa  parasiatarjralQa 

Figure  E.l  DMTITE  CGF  Initialization  File  Format 


E.1.1  <  Entity  Information>.  This  section  specifies  the  callsign,  nationality, 
domain,  category,  and  specific  instantiation  of  the  CGF  in  question.  The  callsign  entry  is 
a  holdover  from  the  Intelligent  Wingman  project;  while  it  identifies  an  unique  “callsign” 
for  the  CGF,  this  value  is  not  currently  used  by  DMTITE.  The  nationality  value  is  an 
integer  specifying  the  nation  the  CGF  represents;  these  values  correspond  to  the  16-bit 
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“coiintry”  field  of  the  Distributed  Interactive  Simulation  (DIS)  Entity  T3rpe  Protocol  Data 
Unit  (PDU)  specified  in  the  DIS  standeird  (IEEE  1278.1-1995,  “Enumeration  and  Bit- 
Encoded  Values”).  The  domain  entry  specifies  the  domain  in  which  the  CGF  operates: 
land,  surface,  air,  and  space  are  the  allowed  values.  Finally,  the  category  and  specific 
entries  refiect  the  taxonomy  category  and  specific  CGF  instantiation  the  CGF  represents 
(e.g.,  a  specific  F-22  in  the  “strike  aircraft”  category).  The  entire  range  of  values  for 
these  entries  have  not  yet  been  specified;  however,  the  category  values  should  refiect  the 
taxonomy  given  in  Figiure  3.3. 

The  strings  specified  for  the  domain,  category,  and  specific  entries  are  converted  to 
their  numeric  equivalents  by  the  routines  defined  in  CODB-Utilities.cc. 

E.1.2  <Initial  Configuration> .  This  section  specifies  the  initial  position  and 

orientation  of  the  CGF  within  the  virtual  battlespace.  The  WGS-84-coordinates  entry 
specifies  the  three-dimensional  (x,  y,  and  z)  position  of  the  CGF  relative  to  the  center 
of  the  earth.  The  CGF  coordinates  are  specified  in  meters.  On  the  other  hand,  the 
euler.angles  entry  specifies  the  orientation  of  the  CGF’s  local  coordinate  system  with 
respect  to  the  earth’s  coordinate  system.  These  angles  are  specified  in  reulians.  Detailed 
information  regarding  geocentric  coordinates,  the  CGF  local  coordinate  system,  and  Euler 
angles  can  be  fovmd  in  the  DIS  standard  (IEEE  1278.1-1995).  The  linear.velocity  and 
linear.acceleration  values  are  specified  relative  to  the  geocentric  coordinate  system  and  are 
measured  in  meters  per  second  and  meters  per  second^  respectively. 

E.1.3  <  Environment  Information>.  This  section  defines  the  environment  with 
which  the  CGF  will  interact.  The  exercise  JD  entry  specifies  the  unique  identifier  for  the 
simulation  the  CGF  is  assigned  to.  The  entity  JD  entry  specifies  the  simulation-unique 
identifier  for  the  CGF  in  question.  The  lead.entityJD  entry  is  used  to  specify  the  CGF’s 
team  leader.  This  veJue  is  provided  for  futiure  use  (when  CGF  cooperation  and  com¬ 
munication  has  been  implemented)  and  will  be  used  primarily  to  determine  the  CGF’s 
“psychological  profile”  (see  Appendix  D).  For  DIS  applications,  these  values  axe  all  inte¬ 
gers. 
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On  the  other  heind,  the  connecLto.CODB  entry  is  a  character  string  specifying  the 
path  and  fileneime  of  the  CODE  to  be  used  to  send  and  receive  world  state  information. 
This  file  will  be  created  if  it  does  not  exist  when  the  CGF  attempts  to  connect  to  it;  if  the 
specified  name  is  incorrect,  the  CGF  will  not  be  able  to  communicate  with  the  rest  of  the 
distributed  virtual  environment.  The  last  entry  in  this  section,  the  domains-ofJnterest, 
specifies  the  number  and  identifiers  of  the  domains  for  which  the  CGF  will  receive  world 
state  information.  The  number  of  domains  is  constrained  to  0-4  (inclusive);  the  allowable 
domain  specifiers  are  land,  surface,  air,  and  space. 

E.1.4  <Entity  Profile>.  This  section  defines  the  number,  identifiers,  and  val¬ 
ues  that  comprise  the  CGF’s  entity  profile.  This  section  should  always  contain  a  mini¬ 
mum  of  eight  identifiers  and  values — stability,  anxiety,  anger,  humor,  acquiescence, 
independence,  charisma,  and  knowledge — since  these  are  expected  by  the  combat  psy¬ 
chology  model  (see  Appendix  D).  Other  profile  identifiers  and  values  specific  to  the  CGF’s 
taxonomy  category  may  be  specified  as  necessary.  Each  profile  entry  consists  of  a  character 
string  and  a  normalized  value  between  0.0  and  1.0  inclusive. 

E.1.5  <Policies>.  This  section  defines  the  number,  identifiers,  and  files  that 
comprise  the  policies  to  be  used  by  the  CGF.  A  policy  identifier  is  a  character  string 
that  uniquely  identifies  the  policy  within  the  CGF’s  knowledge  base  repository.  A  policy 
fileneime  is  a  character  string  that  defines  the  path  and  complete  name  of  the  file  contmning 
the  policy’s  knowledge  representations  (see  Appendix  C  for  more  information  on  these  files). 
Any  number  of  policies  may  be  specified  in  this  section. 

E.1.6  <Knowledge  Bases> .  This  section  specifies  the  number,  inferencing  strate¬ 
gies,  identifiers  and  policies  that  comprise  the  knowledge  bases  available  to  the  CGF.  Each 
knowledge  base  requires  three  physical  lines  to  define  it  completely.  The  first  line  specifies 
the  name  of  the  knowledge  base,  inferencing  strategy  supported  by  the  knowledge  base, 
eind  number  of  policies  that  define  the  knowledge  base.  Valid  inferencing  strategies  are 
case_based,  rule_based,  and  fuzzy_logic.  The  second  line  consists  of  a  description  of 
the  knowledge  base.  This  information  is  not  directly  used  by  DMTITE,  but  is  provided  for 
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debugging  purposes.  The  final  line  specifies  the  identifiers  of  the  policies  that  comprise  the 
knowledge  base.  These  identifiers  must  match  those  specified  in  the  <Policies>  section. 

E.1.7  <Long-Term  EnginO,  <Mission-Level  Engine>,  <Critical  Engine>,  and 
<  Arbitration  Engine>.  These  sections  define  the  attributes  of  each  of  the  decision  en¬ 
gines  to  be  used  by  the  CGF.  In  each  section,  the  first  line  specifies  the  inferencing  strategy 
to  be  supported  by  the  given  decision  engine  (case-based,  rule-based,  or  fuzzy_logic), 
the  number  of  knowledge  bases  accessible  by  the  decision  engine,  and  the  identifiers  of 
each  knowledge  base.  Obviously,  the  knowledge  base  identifiers  must  match  those  in  the 
<Knowledge  Bases>  section.  This  information  must  be  specified  on  a  single  line. 

If  the  decision  engine  is  not  to  be  av2iilable  to  the  CGF,  an  inferencing  strategy  of 
no_inf  erence  must  be  specified  and  the  niimber  of  knowledge  bases  should  be  set  to  zero. 

The  contents  of  the  remainder  of  each  section  is  unique  to  the  inferencing  strategy 
to  be  employed  by  the  given  decision  engine.  The  exact  contents  and  format  for  each 
inferencing  strategy  has  yet  to  be  determined. 

E.1.8  <PSII>.  This  section  specifies  the  files  that  define  the  state  message 
formats  and  data  queries  supported  by  the  Physical  State  Information  Interface.  Each 
entry  is  a  character  string  that  specifies  the  full  path  eind  name  of  the  file  to  be  read. 

E.1.9  <Physical  Components>,  This  section  specifies  the  number  emd  identifiers 
of  the  physical  components  to  be  used  by  the  CGF.  Each  identifier  is  a  cheuracter  string  that 
uniquely  identifies  a  physical  model;  currently,  only  scripted-aircraf  t,  optical-sensor, 
simple-radar,  unguided-ordnance,  and  guided-ordnance  eire  defined.  (As  additional 
models  are  incorporated  into  DMTITE,  the  corresponding  identifiers  should  be  added  to 
the  appropriate  function  in  utility.cc.)  After  each  identifier  are  optional  arguments;  these 
are  assumed  to  be  unique  for  each  physical  model  emd  are  passed  to  the  model  diuring  its 
initialization. 
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E.1.10  <  Sensor  Interface>.  This  section  specifies  the  files  that  define  the  state 
message  formats  and  data  queries  supported  by  the  Sensor  Interface.  Each  entry  is  a 
character  string  that  specifies  the  full  path  and  name  of  the  file  to  be  read. 


E.1.11  Kinitial  Parameters>,  This  section  defines  any  variable  values  to  be 
passed  to  the  Cognitive  Representation  during  its  first  update  cycle.  These  values  may 
refiect  initial  parameters  such  as  seeirch  modes,  specified  target  identifiers,  and  so  forth. 
Each  variable  is  specified  by  a  unique  identifier  (character  string),  a  data  type,  and  a  value. 
Valid  data  t3rpes  are  specified  in  Table  E.l;  corresponding  values  should  refiect  the  data 
t3q)e  in  question  (e.g.,  integers  for  integer). 


Table  E.l  Data  Type  Identifiers  Supported  by  DMTITE 


Data  Type 

Data  Type  Identifier 

integer 

integer 

imsigned  integer 

unsigned-int 

short  integer 

short 

unsigned  short  integer 

unsinged-short 

long  integer 

long 

imsigned  long  integer 

unsigned_long 

fioating  point 

float 

double  precision  (32  bit) 

double 

double  precision  (64  bit) 

long-double 

character 

char 

signed  char^lcter 

signed-char 

unsigned  character 

imsigned-char 

string 

string 

booleein  (true/feJse) 

bool 

E.2  Partial  Example 

A  partial  initialization  file  was  created  to  test  the  implementation  of  the  DMTITE 
architecture.  This  file,  while  not  complete,  represents  a  “best  guess”  of  an  einti-aircraft 
artillery  CGF  with  a  case-based  mission-level  engine,  no  long-term  or  critical  decision 
engines,  and  an  arbitration  engine  that  does  not  have  access  to  the  combat  psychology 
model  (no  inferencing  strategy  is  specifiedfor  this  engine).  The  following  sections  describe 
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the  pertinent  detedls  of  this  sample  initialization  file  with  the  intent  of  providing  a  sense 
of  the  scope  and  “flavor”  of  a  standard  DMTITE  initialization  file. 

E.2.1  Entity  Information.  Figure  E.2  contains  the  first  three  sections  of  the 
AAA  initialization  file.  This  CGF  is  assigned  to  the  Commonwe2Jth  of  Independent  States 
(which  has  a  DIS-defined  nationality  value  of  222),  operates  in  the  land  domain,  and 
represents  a  generic  direct  artillery  site.  Since  AAA  sites  can  not  attack  or  defend  against 
entity  operating  on  land  or  sea,  this  CGF  only  receives  information  about  entities  operating 
in  the  air  domain.  To  obtain  its  world  state  information,  it  connects  to  a  CODE  named 
“airCODB”  that  is  located  in  the  same  directory  from  which  this  CGF  is  initiated. 


<Entity  Information> 

callsign 

Quasimodo 

nationality 

222 

domain 

land 

category 

direct .artillery 

specific 

generic 

< Initial  Conf iguration> 

WGS.84-CO  ordinates 

4788340.0  2792480.0  3146950.0 

euler^angles 

0.0  0.0  0.0 

linear-velocity 

0.0  0.0  0.0 

linear-acceleration 

0.0  0.0  0.0 

<Environment  Information> 

ezercise-ID 

100 

entity_ID 

200 

lead-entity-ID 

9999 

connect-to-CODB 

airCODB 

domains-of -interest 

1  air 

Figiure  E.2  Sample  Initialization  File:  Entity  Information 


E.2. 2  Entity  Profile.  Figm:e  E.3  shows  the  contents  of  this  CGF’s  entity  profile. 
The  basic  eight  values  used  by  the  combat  psychology  model  are  defined;  a  value  of  0.5 
indicates  this  CGF  has  “average”  values  for  each  of  these  profile  attributes.  An  additional 
attributes,  visual -accuity  is  also  defined.  This  skill  is  used  by  the  AAA  CGF  to  deter- 
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mine  the  maximum  range  at  which  it  can  visually  identify  a  potential  target.  This  CGF 
has  an  “average”  visual  accuity. 


<Entity  Profile> 

9 

stability 

0.6 

anxiety 

0.5 

anger 

0.5 

humor 

0.5 

acquiescence 

0.6 

independence 

0.5 

charisma 

0.6 

knowledge 

0.6 

visual-accuity 

0.6 

Figure  E.3  Sample  Initialization  File:  Entity  Profile 


E.2.S  Policies  and  Knowledge  Bases.  As  shown  in  Figure  E.4,  this  CGF  currently 
has  only  a  single  policy  and  knowledge  base  available  for  use.  Its  “general  search”  policy 
defines  general  knowledge  pertaining  to  target  search  and  identification.  This  knowledge 
is  stored  in  a  file  named  AAAsearch.pol,  located  in  a  subordinate  directory  named  data.  In 
tmu,  the  “search”  knowledge  base  uses  this  policy  to  partieJly  define  the  total  knowledge 
available  to  the  CGF  while  it  is  searching  for  potential  targets.  Both  the  policy  and  the 
knowledge  beise  eire  defined  for  use  by  a  case-based  inferencing  strategy. 

<Policies> 

1 

General-Search  data/AAAsearch.pol 

<Knowledge  Bases> 

1 

Search  case-based  1 

Contains  knowledge  pertaining  to  the  seeurch  phase. 

General-Search 


Figure  E.4  Sample  Initialization  File:  Policies  and  Knowledge  Bases 
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E.2.4  Decision  Engines.  Figure  E.5  shows  the  decision  engine  configiu:ation  for 
this  CGF.  No  inferencing  strategy  has  been  specified  for  either  the  long-term  or  the  critical 
decision  engines;  as  a  result,  these  engines  are  not  available  to  this  CGF.  The  arbitration 
engine,  although  having  no  inferencing  strategy  specified,  is  available;  however,  it  will  not 
be  able  to  access  the  combat  psychology  model  (which  would  normally  be  specified  as  a 
knowledge  base  accessible  to  this  engine).  The  only  “complete”  decision  engine  available  to 
this  CGF  is  its  mission-level  engine.  This  decision  engine  employs  a  case-based  inferencing 
strategy  and  has  access  to  the  “search”  knowledge  base. 

A  case-based  inferencing  strategy  requires  an  index  and  weighting  scheme;  this  infor¬ 
mation  is  contained  in  the  remainder  of  the  <Mission-Level  Engine>  section.  Each  fi:ame 
(or  group  of  related  knowledge)  consists  of  ten  variables,  one  of  which  (current-state)  is 
the  indexed  variable.  With  the  exception  of  the  index,  each  variable  has  an  equal  weight 
towards  determining  which  frame  best  fits  the  current  world  state. 


<Long-Term  Engine> 
no-inference  0 

<Mission-Level  Engine> 
case-based  1  Search 

current-state 

10 

current-state 

0 

searchjnode 

1 

f ireunode 

1 

target-visible 

1 

t  arget -det  e  ct  ed 

1 

in.radar-LOS 

1 

in_optical_LOS 

1 

in-engagement  -range 

1 

target-inbound 

1 

time-not-visible 

1 

<Critical  Engine> 
no-inference  0 

<Arbitration  Engine> 
no-inference  0 

Figure  E.5  S2imple  Initialization  File:  Decision  Engines 
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E.2.5  State  Messages,  Physical  Components,  and  Initial  Parameters.  The  re¬ 
mainder  of  the  S2imple  initialization  file  is  shown  in  Figure  E.6.  These  sections  specify 
the  filenames  of  the  state  message  data  structures  to  be  used  by  the  PSII  and  the  Sensor 
Interface;  different  files  aire  specified  because  of  differences  between  the  state  messages 
maintained  by  these  repositories.  This  CGF  uses  only  a  single  physical  model,  represent¬ 
ing  its  optical  sensors  (e.g.,  eyesight),  and  has  its  initial  state  (searching),  search  mode 
(visual),  and  fire  mode  (optically  tracked)  specified. 


<PSII> 

data/AAA-PSII .psi 
data/ queries . tzt 

<Physical  Components> 

1 

optical-sensor 

<Sensor  Interface> 
data/AAA.5ensor_Interf  ace .  psi 
data/queries , txt 

<Initial  Parameters> 

3 

current-state  int  0 

search-mode  int  1 

fire-mode  int  1 


Figure  E.6  Sample  Initialization  File:  Miscellaneous 
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